Hi everybody,
I have been doing a lot of constituent imports lately and am having a lot of trouble with the Identify Duplicates part of the Utility. In essence, it doesn’t seem to be catching all of our duplicates. I checked the Duplicate Matching settings in our T_DEFAULTS table and they seem to be sufficient, but regardless, it is not identifying duplicates even when they match these parameters – when the import name and address information is really, exactly the same as what exist in the db. For reference, our duplicate matching settings are as follows:
fname=1,lname=20,postal_code=3,street1=3
Has anyone seen this happen before? To note, we are still on v.10.
Thanks!
Frannie
That "lname=20" looks awfully long to me. At the moment we are running with these values in T_DEFAULTS:
fname=2,lname=3,postal_code=4,street1=4
This string is the result of lots of experimentation. It finds perhaps more false positives than we'd like, but results in the best output for us, for now. (For v11 it finds lots of Households that aren't dupes, and hopefully the standard dupe code is being improved for v12.)
All that said, I've never trusted the identify dupes portion of the constituent import process, and have preferred to import without it, then look for dupes as a separate process. YMMV, as always...
Thanks Chris. Per your advice I adjusted our Duplicate Matching settings, but the utility is still missing a HUGE percentage of duplicates that match the criteria.
Is this a known problem for anyone else?
Or Chris, what do you do if you import constituents without letting the utility check for duplicates? Do you rely on the Merge Constituents screen? Or does your org have other custom checks?
Any advice welcomed - this is becoming hugely time-consuming and messy. We at times have imports of 900+ constituents--Tess will detect about 150 dupes when the utility runs in Review, and if I spot check, I can find up to 400-500 more. Pulling my hair out!
Thanks all--
Frannie,
I would check the @changed_since_days parameter on your AP_IDENTIFY_DUPLICATES procedure. Here is an excerpt from the documentation on identifying dups.
"@changed_since_days – Each time the procedure runs, the list of potential duplicates is cleared. By default, a pair of potential duplicates that is not merged will not be added to the list of potential duplicates again unless one of the records had activity since the last time the procedure ran. The activity date window can be specified in days using the optional @changed_since_days parameter.
For example, if the @changed_since_dates parameter is set to 30, one record in a potential duplicate pair must have had activity within the last 30 days in order for the pair to be included in the results. Setting @changed_since_days to a time period of several years will refresh the list of potential duplicates so that old pairs that were not merged can be reviewed again."
Dale
Thanks for the tip Dale. I checked our @changed_since_days parameter in the AP_IDENTIFY_DUPLICATES procedure, and the variable is set to NULL. I am thinking that this setting means there is no limit to how recently an account must have had activity for Tess to include it as a potential duplicate.
If there are any others with similar experiences or a fix I'd love to hear.
Thanks,Frannie
If your @changed_since_days is set to Null then I would expect the default behavior which according to the documentation is: "By default, a pair of potential duplicates that is not merged will not be added to the list of potential duplicates again unless one of the records had activity since the last time the procedure ran."
Try changing your @changed_since_days to a large number like 730 (2 years) and see what happens.