Any ideas on how I can make it so that if the incoming address is above my score threshold on the preferred address of the record then auto-select that address even if there are other addresses on the record that also score above the threshold?

I understand why you need to pop up the address processor if multiple addresses are above the score, but if one of those is the preferred one then that is an easy choice to make and you don't need to show me the other alternatives.

I have a lot of close addresses because of some bad AddressFinder imports (i.e. the address only differs by the +4 on the zip code).  These both match with the same score because it only looks at the Address 1 line so it will ALWAYS pop up the address processing form even if I have already marked one of them as preferred.

currently I am fudging the score matches by checking the incoming address against the preferred address in AfterConstituentOpen (before address processing) and copying over the current RE data to the import file if it is close enough.  For example, if the incoming data doesn't have the +4 but RE does then I copy the RE data to the import file so when the address is processed the zip codes match.  I also do this for apartment numbers as many times incoming addresses will omit the apartment number or they will use # instead of Apt or something like that.

This has helped speed up my importing but I still get a lot of "ignore" clicking because of similar alternate addresses when I would always want to choose the Preferred address if it's an option (i.e. above my score threshold).

We are having the same problem here since we often have duplicated addresses when we pull from another DB. Any help would be appreciated!

Hi guys,

Definitely appreciate the feedback. One thing that doesn't factor into the similarity score is Address Type. So, let's say we've added this option as a checkbox in the similarity score section that says "If multiple addresses exceed similarity score and one of them is primary, select the primary". Let's also say you've selected that option. Now you have a constit with an address of type "Home" and you import the same address again but with the type "Business". Should it just update home if the address is the same and not create the business address? Or would the address type of the existing Home address update to "Business"? OR, instead, should our option be "If multiple addresses exceed similarity score and one of them matches by Address Type, or one of them is primary and no address type is specified, select that one"?

Thanks for your feedback guys, we definitely are interested in continuing to make ImportOmatic more Omatic-y!

Jeff

I would want them to NOT automatically overwrite if they were different types. I think that should pop up the form. It would be extra nice if it told you why it didn't auto-match but I realize that might be hard to pull through.

If anyone would want to match ignoring type you could always make that a separate checkbox but I don't really think that is going to happen.

Hi Jeff, thanks for the VERY quick reply!
We are fairly new IOM users at our organization, but we are trying to dive into the deep end... for our purposes, we are usually just concerned that we are not putting a new address in the system if the same address (or similar) already exists somewhere. For that reason, we have to click "ignore" a bunch when the address being compared appears twice on a constituent record, rather than IOM automatically ignoring the new address because it already exists on the record.

I can see cases where folks would want to auto-match based on more specified criteria... so here's some suggested options:

If multiple addresses exceed similarity score:
-Always show advanced address processing
-Always Ignore the address being imported
-Auto-match using these criteria (user selected):
-Attempt to auto-match first to preferred address
-Attempt to auto-match based on import address type
-Auto-match to first matching address type in this order:
-Home
-Business
-Alternate
-Etc.
-Auto-match by date of newest matching record

Thanks again for your help!

Brad, can I ask why you have so many similar matching addresses?

Is it a problem with dupe address records or do you really have multiple legitimate addresses on a record that are very similar?

What score are you currently using to match addresses? I usually have mine at 90 but I also ignore +4 on the ZIP and the apartment numbers (through the API) so I more often get a 100% match. The score only takes into account the address lines, it will not auto-match if the city/state/zip is different.

Hi Wayne,
Thanks for the follow up, and thank you for contributing so much on these forums. We just started using IOM a few weeks ago, but have benefited tremendously from the notes you have submitted and the RegEx and API examples you've given.

We have our matching "score" matching set around 91, but our address matching score set in the 70s. This is a good score for us because small variations on imported addresses from our other systems will otherwise cause several more pop-ups to show up if we don't keep it this low.

We tend to have many similar or identical addresses on one constituent record due to past imports (centralizing data from various departments) and even if we were able to clean these up easily (suggestions?), a future import plan we have will cause us to keep identical information with our student information system available in RE (our SIS keeps 3 addresses - student, local and billing, but they are often the same).

Most of our "advanced address processing" pop-ups currently come not because different addresses match the score, but because we have several identical addresses in RE that match the one being imported.

On a side note with your other topic:
I think I read another post here that said the +4 import issue has been dealt with by Omatic https://www.omaticsoftware.com/Forums/tabid/108/aft/60/Default.aspx but matching apartment issues are pretty crucial to us since we have students in on-campus apartments.

Seems you are in a bit of a different situation than I am.

One possible solution is to do the address match through the API instead of in the normal profile. In AfterConstituentOpen you could open up the preferred address on that record and then compare the data to what is being imported. If you find that it matches (and therefore does not need an update) then you can delete the data from the import fields and it will not ask about the address since it will not be trying to import one.

That way the address would only pop up when it was actually different than the preferred address on the record but you would still be able to use the imported address to match constituents (since that happens before IOM tries to create/update addresses).

Does that make sense?

Hi Gordon,

Thanks for your feedback! Just to set expectations, it takes a lot longer to get changes out the door than to talk through them, so I don't want you to think a programmer is jumping on it at this moment, but we do review our feedback (particularly in our UserVoice forum) before planning each new release. You obviously spent a lot of time thinking about the criteria. At first blush I'm not sure we'd go that deep (I shudder at trying to explain all that to new RE user), but I will think on it. If we did not, would the option below be pretty good improvement?

"If multiple addresses exceed similarity score and one of them matches by Address Type, or one of them is primary and no address type is specified, select that one"

It seems that would significantly reduce pop-ups in the case of the same address existing multiple times? Let me know as you're doing your processing if that is correct.

Thanks,
Jeff

No worries, I'm aware of how long changes take to decide upon and implement! That being said, it is appreciated to have the immediate feedback from a rep to a user forum post, so thanks. A simple check box as you are suggesting would work just fine for our situation.

As Wayne suggested an API solution will probably be our answer for now. Can you compare an address based on a score using the API? For example, if we had an import that was slightly off from the records in our system (say the import used Apt, and the preferred address in RE used #) would the API be able to compare those and ignore the address update as Wayne suggests? Also, would it be possible to cycle through all of the addresses and ignore the import if any of them were above a certain similarity score?

The API gives access to the score functionality.

Something like:
bMatch = False
For Each iAddress In oRec.Addresses
    If Import.ScoreSimilarity(sImportAddr, sCurrentAddr) > 90 Then
        ' If it is more than 90 similar to the current preferred address then set the flag
        bMatch = True
        Exit Loop
    End If
Next oAddr

If bMatch = True Then
    'Delete the Import Fields because there was a match
End If


See my post here for an example of something like this: http://www.omaticsoftware.com/Forums/tabid/108/aft/1308/Default.aspx

Thanks, Wayne!