Use this link to share with your colleagues:
Account and Contact Deduplication: https://help.pm.leapevent.tech/a/1253666
Once your initial data has been imported into PatronManager, we'll move onto managing the duplicates that may now exist. Duplicates can occur in your historic data for a number of reasons including:
- Separate systems for Ticketing and Fundraising
- Inconsistent data entry practices
- Differing data structure between PatronManager and your legacy systems
- Patrons/Donors have provided different information over time
The deduplication step of your Data Migration will identify and merge many of these duplicate records. Once you're operational in PatronManager, you'll have additional tools such as Qualification and Salesforce's Duplicate Management to keep your database clean and tidy.
How does deduplication work?
We use an extremely robust third-party tool that identifies possible duplicate accounts and contacts based on a series of criteria. When two (or more) accounts are merged, one account is designated as the "Master" account, and all field values and related records of the secondary account(s) shift over to the Master record.
The deduplication tool uses the following standard logic to merge field values:
- Where two matches have identical or near-identical field information, the system will automatically select the account with the most related donations and/or contact records as the Master account.
- If the Master record has an empty field and the Secondary record has a value, the record containing a value will "fill in the blanks" on the Master record.
- Values listed in Text Area fields, Multi-Select Picklist, and Boolean (true/false) fields will be combined on the Master record.
- Secondary account field values will never overwrite the Master record, unless a rule has been created to explicitly allow for this to happen.
What's the process of deduplication look like?
During the initial deduplication, we will identify all "clear" matches, where two accounts represent the same patron's account without question. Our initial deduplication merge passes will run on the following criteria:
- Rigid Criteria: Account Name, Billing Street, City, Postal Code, and Phone all must match
- Semi-Rigid Criteria: Account Name, Billing Street (Relaxed Address Match - identifies matches based on partial information, such as an address without a Suite or Apartment number), City, Phone (Relaxed Phone Match - identifies matches based on partial information, such as a phone number without an area code)
- Loose Criteria: Account Name, Billing Street (Relaxed Address Match), City
- Very Loose Criteria: Billing Street (Street Address Match), City, Phone (Relaxed Phone Match)
As we loosen our criteria, we will see fewer "clear" matches. If two records don't share at least two matching criteria (such as a Name + Address), we will not merge them without your review.
Here's an example:
In this example, we'd merge the second and third Veronica Corningstone records since the name, phone, and address (even with the spelling difference) match. We wouldn't merge the first record since there's only one piece of information that matches (in this case, the Account Name).
Once we've exhausted all obvious duplicate matches, we'll generate two files of potential duplicate accounts for your team to review. In most situations, these files will likely consist of:
- Duplicate Accounts - Name Match: This file will contain groups of accounts where the Account Name matches exactly between records, but the accounts have a conflicting (or empty) address field.
- Duplicate Accounts - Address Match: This file will contain groups of accounts where the Account Address matches exactly between records, but the accounts have a conflicting Account Name. This is sometimes a name spelling difference, but may also be two members of the same household that purchased tickets under their own account name.
We will provide a deadline for your team to return the file with your revision notes, from which we will merge the remaining accounts.
After we've merged the remaining accounts according to your revision notes, we will complete the deduplication project by merging any duplicate contact records that live within the same account.
Can you merge duplicate transaction records, too?
Deduplication is limited to Account and Contact records. During the initial data migration, any duplicate transaction records should be removed prior to submission of data, as we cannot "merge" two transactions.
The dedupe is complete, but I'm still finding duplicates!
It is completely normal to still have duplicate records within your account. Our tool is extremely robust and will take care of the vast majority of duplicate matches, but it can't catch every potential match. (This is why data maintenance is so important!)
Here are a few examples of duplicate records you may come across that will not be addressed during our deduplication process:
- An account has two contacts that are the same person, but each record has a different email address.
- A duplicate contact lives in a separate account, but the account name is slightly different and the address is blank.
Managing Duplicates Moving Forward
PatronManager offers a couple of different ways to manage new duplicates that may come into your system as patrons purchase tickets and donate to your organization:
- Qualification can help stop duplicates from being created in the first place
- Merge Accounts and Contacts in Lightning
- How to Merge Older Duplicate Accounts and Contacts