Hello all,
I am hoping to get a sense of how different orgs manage their merging of duplicates. I have read on the forums about some great examples from a couple of years ago of people scheduling the Identify Duplicates procedure, and having a daily task of manually putting them into the Merge queue.
Some people appeared to have been confident enough to merge constituents automatically if they meet the criteria.
I would love to hear how many people are automatically merging duplicates, and how many people are doing it manually, which is how I was always taught.
At ACMI, we have thousands of duplicate accounts from importing e-news subscribers over time. The bulk of these accounts only have First Name, Last Name and email. We are working with Tessitura consultants to get our Identify Duplicates logic to pick theses up, and would very much like to merge automatically as many as possible.
Thanks all!
Nicholas
When we went Live with Tess in 2008 we found a large number of fairly straightforward dupes that were identifiable due to the more powerful tools available on SQL Server, and we merged those en masse.
We have not auto-merged any records since then.
Looking for address-less, name + e-mail only dupes is something we look for regularly via custom SQL code.
I have been involved in many discussions about this. There is an understandable amount of trepidation among department heads about the possible fallout from merging records without any human intervention. However, there have been a few cases when I have implemented it.
The one case where it has been most successful is with accounts created on the web. But we used really strict criteria. At one point we implemented a nightly process which would merge records if the following were true:
- The Delete account was created on the web the previous day.
- Both the first name and last name are an exact match
- The postal address is an exact match
- The email is an exact match (this one may have been deprecated later, I can't recall)
What we are trying to catch is existing patrons who did not previously have a web login. So when they hit the website the first time to buy tickets, they have to create an account. We are then grabbing those new accounts and merging them into their existing account.
This is a really specific case. I would have trouble recommending automatic merging for anything more complicated than this. Especially with the household model in V11 and beyond. There are a lot of considerations with moving transactions and ensuring that the final product of the merge looks correct.
At ATTPAC, we have a Data Integrity Specialist who schedules all merges for the consortium. It is a labor intensive process, but the results are superior.
- Levi
Thanks all for the great info, very valuable.
Chris, do you use custom SQL code for the no address constituents because the standard Tess Identify Duplicates is not suitable for these "incomplete" records? If you don't mind sharing the SQL code, I would be very interested to see it.
Unknown said: Chris, do you use custom SQL code for the no address constituents because the standard Tess Identify Duplicates is not suitable for these "incomplete" records? If you don't mind sharing the SQL code, I would be very interested to see it.
Yes, the standard matching code and rules of "fname=x,lname=x,postal_code=x,street1=x" work well for name + postal address matches, but I find that matches based on non-postal criteria are easier to find with different and often simpler code. I'll get in touch offline.