CRM deduplication rules
Most deduplication projects are a one-time bulk merge that feels great for a month, and then the duplicates come back because nothing changed at the point of entry. Dedup is a set of written rules: what counts as a match, which value survives, who approves risky merges, and what blocks the duplicate from being created again. Write the rules first and the tooling becomes a configuration exercise.
Download it
What you get
- Matching keys for accounts, contacts, and leads, with the normalization each key needs before comparison
- Match confidence tiers that decide whether a pair is auto-merged, queued for review, or left alone
- Field-level survivorship rules so merges keep the right value instead of the newest one
- A merge approval matrix for high-risk merges such as accounts with open deals or different owners
- A prevention checklist for forms, imports, integrations, and manual entry
Who it's for
- CRM admins planning a deduplication cleanup
- Marketing ops teams whose forms and imports keep creating duplicates
- RevOps leaders who need merge rules sales and finance will accept
What's inside
6 sections, each listed with its own size. The first is previewed below; the remaining 5 come with the download, with blank rows ready to fill in.
| Section | Size | Previewed |
|---|---|---|
| Matching keys by object | 5 columns, 5 worked example rows | Below |
| Match confidence tiers | 5 columns, 3 worked example rows | In the download |
| Survivorship rules | 4 columns, 5 worked example rows | In the download |
| Merge approval matrix | 4 columns, 4 worked example rows | In the download |
| Prevention at the point of entry | 9-point checklist | In the download |
| Why duplicates keep coming back | Guidance notes | In the download |
Preview of section 1
Matching keys by object
Normalize every key before comparison. Tiers decide the action, as defined in the next table.
| Object | Primary match key | Normalization | Supporting signals | Default tier |
|---|---|---|---|---|
| Contact | Lowercase; trim spaces; strip plus-addressing (name+tag@) | Same account; same last name | Tier 1 if same account, else Tier 2 | |
| Lead | Lowercase; trim spaces | Company domain matches an existing account | Tier 1 against other leads; convert to contact if a contact exists |
How to use it
1. Normalize before you match
Lowercase emails, strip 'www.' and paths from domains, and remove suffixes like Inc, LLC, and Ltd from company names before comparing anything. Most missed duplicates are formatting differences, not genuinely different records.
2. Match on keys, not on names
Email for contacts and leads, website domain for accounts. Company name is a supporting signal, never a sole key. Two companies called 'Summit Partners' are common; two with the same domain are almost always the same company.
3. Only auto-merge exact, low-risk matches
Auto-merge contacts with an identical normalized email and the same account. Send everything else to a review queue. A bad merge destroys history that cannot easily be restored, so the cost of a false positive is far higher than a missed duplicate.
4. Write survivorship rules field by field
'Keep the newest record' is not a rule. Decide per field: owner from the record with the open opportunity, lead source from the oldest record, phone from the most recently verified source. Configure your merge tool to follow the table.
5. Fix the entry points before the bulk cleanup
Turn on duplicate blocking for manual entry, dedupe imports against existing records, and set integrations to match before they create. Then run the bulk merge. Cleaning first and preventing later means cleaning twice.
Frequently asked questions
What is CRM deduplication?
The process of finding records that represent the same person or company, merging them into one record with the correct field values, and preventing new duplicates from being created by forms, imports, and integrations.
What fields should be used to match duplicates?
Normalized email address for contacts and leads, and normalized website domain for accounts. Company name, phone, and address are useful supporting signals but produce too many false matches to be used on their own.
Should duplicate records be merged automatically?
Only exact matches with no ownership or opportunity conflicts, such as two contacts with the same email on the same account. Everything else should go to a review queue, because a wrong merge loses history that is hard to restore.
Which record wins when you merge duplicates?
Decide per field, not per record. Keep the record with the most opportunity history as the master, keep the oldest lead source, keep the most restrictive opt-out status, and take contact details from the most recently verified value.