Omatic Support
How can we help you today?
Reassign Preferred Address
17 CommentsSorted by Oldest First
Hi Wayne,
Do you have a column in your profile for Preferred = Yes? Or do you have the option under Addresses selected, "Update addresses that meet or exceed the Similarity Score"? Both of these will mark the incoming address as preferred without manual intervention.
The settings for type, dates, etc won't change for addresses that are being updated; they only apply when a brand new preferred address is imported. You could use the API to make these changes for you, though.
Please let me know if you have any other questions.
Thank you,
Amanda
Omatic Support
Do you have a column in your profile for Preferred = Yes? Or do you have the option under Addresses selected, "Update addresses that meet or exceed the Similarity Score"? Both of these will mark the incoming address as preferred without manual intervention.
The settings for type, dates, etc won't change for addresses that are being updated; they only apply when a brand new preferred address is imported. You could use the API to make these changes for you, though.
Please let me know if you have any other questions.
Thank you,
Amanda
Omatic Support
Hmm, I don't have either of those but I do have a column for "send mail to this address" to be checked. Would that do it?
I don't just want to update all preferred addresses to remove the "to" date. I only want to update the ones that are reassigned by IOM. Is there a way for me to know in the API when the address has been changed/reassigned?
I don't just want to update all preferred addresses to remove the "to" date. I only want to update the ones that are reassigned by IOM. Is there a way for me to know in the API when the address has been changed/reassigned?
Wayne,
CConstitAddress can be typed as an IBBDataObject. The IBBDataObject interface has a Dirty property on it. I haven't tested to see if this will work in your situation but it will let you know if the address object has been changed. Additionally you can use the FieldIsDirty property, it takes the enum of the field you want to check as a parameter.
CConstitAddress can be typed as an IBBDataObject. The IBBDataObject interface has a Dirty property on it. I haven't tested to see if this will work in your situation but it will let you know if the address object has been changed. Additionally you can use the FieldIsDirty property, it takes the enum of the field you want to check as a parameter.
Hi Wayne,
Correction to my previous post - just having "Update addresses that meet or exceed the Similary Score" selected isn't enough to check the preferred checkbox. I still had a column for Preferred = Yes in my profile.
Are you seeing the advanced address processing screen during import? This would mark the address as preferred if you're choosing "Update Selected". Also, if you're seeing the AAP then you can open the address from there and update the date to if the API option doesn't work out.
Thank you,
Amanda
Omatic Support
Correction to my previous post - just having "Update addresses that meet or exceed the Similary Score" selected isn't enough to check the preferred checkbox. I still had a column for Preferred = Yes in my profile.
Are you seeing the advanced address processing screen during import? This would mark the address as preferred if you're choosing "Update Selected". Also, if you're seeing the AAP then you can open the address from there and update the date to if the API option doesn't work out.
Thank you,
Amanda
Omatic Support
Thanks Nic, I will have to try that out! I know in the past I have had a hard time pulling up the edited Address but I guess I can cycle through them all before save to see if one is dirty.
Amanda, is there a way to make a column in a profile for the Date To field that will blank it out? That would work for me I think, it would just set the Date To as blank for any address that is touched by the profile right?
Amanda, is there a way to make a column in a profile for the Date To field that will blank it out? That would work for me I think, it would just set the Date To as blank for any address that is touched by the profile right?
Hi Wayne,
Unfortunately IOM doesn't remove values such as the date to at this time. However, we do have a UserVoice suggestion which I would encourage you to vote on.
Thanks,
Amanda
Omatic Support
As a follow up question, what happens to the email address/phone number when I hit "Ignore" on the AAP? Does it just go on the current preferred address?
Hi Wayne,
Yes, phones and emails are still processed when you choose to Ignore in the AAP and they'll be added to the current preferred address.
Thanks,
Amanda
Omatic Support
Yes, phones and emails are still processed when you choose to Ignore in the AAP and they'll be added to the current preferred address.
Thanks,
Amanda
Omatic Support
Nic, getting back to this "Dirty" thing.
What does that mean exactly? For example, if IOM adds an address to a constituent but otherwise does nothing would the constituent record be dirty? What about in AfterConstituentSave? Does it get "clean" after a save or after the row commit?
Is a constituent always dirty if there is an IOM match even if nothing changes on the record? (like a gift batch import for example where there is an auto-match to the constituent)
I have not tested if child objects off of the CRecord object can affect the Dirty property. My guess is that they do not. You could still loop through all of the addresses and check their status.
As for saving, without testing I can't confirm that Save clears the Dirty flag (it should in theory). Also it would not surprise me if constituent is flagged as dirty even if nothing changes. When you match to a constituent through ID or bio information we are still setting those fields (providing the settings allow for it). Setting those fields even though they are not different from what is already on the field may trigger the Dirty flag. Testing would need to be done to confirm this.
As for saving, without testing I can't confirm that Save clears the Dirty flag (it should in theory). Also it would not surprise me if constituent is flagged as dirty even if nothing changes. When you match to a constituent through ID or bio information we are still setting those fields (providing the settings allow for it). Setting those fields even though they are not different from what is already on the field may trigger the Dirty flag. Testing would need to be done to confirm this.
Thanks Nic, much testing on my side!
One thing I have noticed is that new constituent records have an ID of -1 before they are saved (in BeforeConstituentSave) but in BeforeIndividualRelationshipSave both the relationship and individual record have ids (meaning that they have already been saved) even if they are new records.
I am trying to pick up when a new relationship was added to a record (as opposed to just editing an existing one) and if it was made to an existing constituent or a new one created by this import.
Any ideas there? One thing that seems consistent is that the record is marked dirty but no fields are dirty so I might be able to use that. Seems prone to bad assumptions though.
I am trying to pick up when a new relationship was added to a record (as opposed to just editing an existing one) and if it was made to an existing constituent or a new one created by this import.
Any ideas there? One thing that seems consistent is that the record is marked dirty but no fields are dirty so I might be able to use that. Seems prone to bad assumptions though.
Wayne,
I don't think you will have all the information you need to determine this 100% of the time. Best we can do without code changes to IOM is 99.9% of the time. Check the date created field on the record object and compare it to the current time to see if it is a new constituent. You can do the same to the relationship record to see if it is a new relationship. The times won't be exact but you can allow for some variation by a couple seconds either way.
I don't think you will have all the information you need to determine this 100% of the time. Best we can do without code changes to IOM is 99.9% of the time. Check the date created field on the record object and compare it to the current time to see if it is a new constituent. You can do the same to the relationship record to see if it is a new relationship. The times won't be exact but you can allow for some variation by a couple seconds either way.
That was one of the options, checking the creator = Import.REUsername and Date close to now.
What I have ended up with is that I assign a special addressee to all new records through the default addressee setting in IOM called "IOM New Record" and I check to see if that is set to determine whether it is new or not. Then I go on to actually set the correct addressee for the record through the API (since I can't really do that until I have finished adding relationships anyways).
It works but it's ugly!
What I have ended up with is that I assign a special addressee to all new records through the default addressee setting in IOM called "IOM New Record" and I check to see if that is set to determine whether it is new or not. Then I go on to actually set the correct addressee for the record through the API (since I can't really do that until I have finished adding relationships anyways).
It works but it's ugly!
Help Desk Software
by Freshdesk
Wayne Pozzar
I have a process question about assigning the preferred address on a record.
Starting with this scenario:
If a gift comes in with address B for the donor IOM seems to just switch which address is preferred but leaves everything else alone (type, date to, etc.)
Is this expected? I would like to treat reassignment of preferred address the same way that I treat a new preferred address as the settings in the profile indicate.