I would add this - if the Address section, being a Child of the Parent section for Constituent, could differentiate if the Parent object were New or not (Parent match-found), then the logic for Add from Classy could be expanded. If No-Match, but Parent Match, then skip. This would allow us to keep unwanted 'Home' Addresses out of our system where the data difference is only due to Standardized (RE) versus non-Standardized (Classy) address details.

We're passing the Classy Supporter ID into an RE Alias and making RE Alias the Primary match. Thus, repeat donors are pure 1-1 matches and are Ready records. Would be nice to match 1-1 and not have new Home Addresses popping-up everywhere.

I am finding that there are some benefits of using cloud over some of my previous pre-processing of data and then using IOM to now using Cloud where it will check to see if the address already exists on the record. However, I am finding that I need to run at least one other import or manually update records to update the "former" information on records because of the lack of any possibility to do that in cloud. Therefore I am not really saving any time by using cloud for that functionality. We keep all addresses on record, even if there is a slight change in the address for history purposes.

this is one of the most critical functions, I don't think this product is usable for processing address updates unless we have the ability to properly handle incoming addresses and previous addresses.

Setting the old address to "Previous Address" should absolutely be possible with this import. I don't want to have to go back to ImportOmatic for this one import.

This is absolutely necessary for us to be able to update addresses returned to us electronically by the post office. When we use intelligent mail barcodes on our mailings, the post office returns an electronic file of updated change of address, bad addresses, and those who are temporarily away from home. Using OC to import this process cannot be done without (we counted!) 8 ADDITIONAL steps we have to do now that we didn't have to do with IOM. That is crazy to take away a critical function when giving us an "updated" import process.

Because of the lack of development with this issue we no longer us the formula that was built to connect our online gift platform to our database. Instead we download everything to an excel sheet, run a macro to tweak the addresses to our preferred formatting and then upload that spreadsheet into OC. It's a shame we can't use the formula we spent a lot time developing, but it just wasn't serving us the way we need it to.

This is absolutely critical, we can not use the OC for address updates until this is fixed, we will be forced to continue using the Database View. We run thousands of our current donors through the DV ImportOmatic each week, with hundreds of records regularly flagged as possble new address, when in fact only a handful of those turn out to be actual address updates. The current OC address processing would damage the integrity of our donor data.

We "need to be able to update a new address while saving the old address as a former address." OR
at least an option to add all addresses when creating a new donor record, but NOT to update and overwrite an address for existing records.
-Unfortunately we have events where donors do not enter their entire address to register or give through an event, and while the match is found for the donor's record via name & email, I do not want the BLANK address to update over the existing address in our CRM, but I would still like the address to be added from Omatic when creating new records. Thank you

We need this feature for our imports as we can't make use of the Omatic Cloud as long as it's not there.
Thank you!

We need this to be done! Correct addresses are critical.
Thank you.

If I'd known that OC couldn't match on fuzzy addresses, use a partial find-and-replace address standardization transformation, OR have Advanced Address Processing options, I wouldn't have upgraded our organization from IOM until at least one of these features was available! Now I'm just paying extra for OC waiting for features that should have come standard while still doing everything through IOM. Blargh.

This development should be top priority. The current limitations in Omatic Cloud's address processing are causing significant inefficiencies and additional clean-up work for our organisation. We need advanced address processing to address data integrity concerns, enable historical tracking, and eliminate manual workaround. Additionally, for Australian customers, the ability to process AUS/NZ address formats is essential to ensure accurate and reliable data handling

We would love this option.

Without this implemented, we will not be able to utilize the most importing with Omatic Cloud and we will not be able to implement using the Donor Drive connector for our biggest event of the year. Moving to the cloud should be more efficient for our data needs, not less. Not having the functionality with the regular expressions dictionaries, or something better, is not an option for our needs.

I need the option to select what address or information is in NXT over what is in the data file or what is in the data file over NXT and have that be my decision and not have what I've selected be over written

I have to manually enter addresses for all new records which is super time consuming.

I second what Ellie said- We need to be able to add new address and move old to a designated prior address type and add end valid date.

Yes! We also keep track of all former addresses and I have been looking to find a way to mark other addresses as Previous and mark a valid date to field. When importing via Address Updated in RE, it has that capability.