Event Registration-Duplicate names, Overwrite on Contact Records

Question

Due to using the same email, we have had tons of event contacts histories overwritten with another contact name besides duplicate name entries during registration of events. With the upgrade to 4.6.10 I am monitoring same. Currently I am still finding duplicate contact names in the system. I am unsure of overwritten accounts until such a time where I discover same. I know there is a few drop downs under duplicate emails in events/on-line registrations. Which is the best to check off? Right now it is on unsupervised. Under Events-on line registration we also have checked off register multiple participants and same email address.

I have to go back 9 years to fix all records. I would like to not have to do this anymore.

@Lesley Carter-BackOfficeI messed with the dedupe and things are now messed up, got this error:

An error has occurred. 0 @import url(/administrator/components/com_civicrm/civicrm/css/civicrm.css); @import url(/administrator/components/com_civicrm/civicrm/bower_components/jquery-ui/themes/smoothness/jquery-ui.min.css); Sorry but we are not able to provide this at the moment. Supervised rule for Organization does not exist

Return to home page.

function toggle( element ) { var className = element.className; if ( className == 'crm-accordion-wrapper collapsed crm-fatal-error-details-block') { element.className = 'crm-accordion-wrapper crm-fatal-error-details-block'; } else { element.className = 'crm-accordion-wrapper collapsed crm-fatal-error-details-block'; } }

Answer 1

Yes, adjusting and using the Unsupervised rule is your best bet to prevent this from continuing. My philosophy for deduplication is I would rather default to having extra duplicate contacts that I can clean up later than having two people become intertwined and, as you've experienced, can be rather sticky to separate.

Ideas

There are a few ideas thrown around in the comments of this question: Dedupe Rule not working. (Full disclosure: I have an answer on that question). Lesley also has a great recipe in her initial comment to you up above.

Best write up about deduplication

The best free resource for Deduplication understanding and recipes is this blog post by spidersilk: Understanding CiviCRM Dedupe Rules. Section 6 is titled 'Some Recommended Rule Recipes' and section 11 is 'Tips for Setting up Effective Dedupe Rules'. The whole article is excellent, but for a tldr; those sections are great.

An Extension that could help

The No Overwrite extension can help with accidental over-writes in certain cases and might be worth installing. We have it installed on our CiviCRM setup.

How we do it

Lastly, just for another example, we have a lot of children in our organization being registered. A parent will often use his/her own email address to register a child, so we had to come up with a way that was more than just email. Our unsupervised rule is as follows:

First Name; Length - 4; Weight - 5.

Last Name; Length - blank; Weight - 5.

Birth Date; Length - blank; Weight - 10.

Email; Length - blank; Weight - 10.

Weight threshold - 20

This allows matching if the birth date and email address are the same (the only scenario this doesn't work is identical twins, and I'm okay with that risk). Also, if this is a normal adult registration (and adults normally don't provide their birth date), we can still have a match based on first four characters of the first name, the last name matching, and the email matching.

This catches a lot of duplicates, but certainly not all of them. Thomas Smith and Tom Smith with the same email address is probably going to be the same person, but our rule will not catch it. And I'm okay with that. Again, I'd rather have extra duplicate contacts than incorrectly intertwined contacts. As a matter of practice, every month or so we manually run General dedupe rules that are "Email only" or "First Name and Last Name" to catch the extra duplicates. Yes, it's manual work, but it's way easier to take the time for that than separating two people who were not in fact the same.