Duplicate detection, merge review, and survivorship
Find CRM duplicates without destroying real records: match signals, confidence thresholds, an adjudication step for ambiguous pairs, and survivorship rules that say which value wins.
On this page
- Matching is not the hard part
- Confidence thresholds need three outcomes, not two
- Account-level merges carry more consequence than person-level merges
- Protect records a merge could quietly harm
- Survivorship: decide per field family, not per record
- GTM Lab: the pair that looks like one person and isn't
- Salesforce and HubSpot: what changes, what doesn't
- Duplicate detection checklist
- Where this connects
Two people can share a surname and an employer domain. A rules-only fuzzy matcher will merge them, and merging destroys both of their independent histories at once. A duplicate-detection pipeline needs more than a matching rule. It needs a confidence threshold, an adjudication step for the pairs that aren't obviously safe, and a survivorship rule that says which value wins when the merge does happen.
Matching is not the hard part
Exact-match signals (a verified email address, a platform-supplied unique ID) are cheap and reliable. Fuzzy signals (name similarity, company-domain overlap, phone number) catch more real duplicates and also catch more false positives. The hard part isn't finding candidate pairs. It's deciding what to do with the pairs that aren't clearly one or the other.
| Signal | Trust level | Notes |
|---|---|---|
| Exact email match | High | Still verify the email is current, not just present |
| Verified platform ID (converted-Lead reference, external system key) | High | Only as reliable as the process that assigned it |
| Fuzzy name + company match | Review-required | Catches real duplicates and same-surname/same-employer false positives at similar rates |
| Phone number match | Review-required | Shared office lines and outdated numbers both produce false positives |
Confidence thresholds need three outcomes, not two
A two-outcome model (merge or don't) forces every ambiguous pair into a guess. Use three:
- Auto-merge: confidence is high enough that a human review adds no real signal. Reserve this for exact-match-backed pairs.
- Human review: confidence is plausible but not certain. The pair is held with its match evidence attached, not merged, until someone (or a second adjudication pass) confirms it.
- No match: confidence is too low to route anywhere; discard the candidate pair.
The review tier is where most of the actual judgment lives. A fuzzy name-and-company match sitting at moderate confidence is exactly the case that catches two distinct people who happen to share identifying signals. Auto-merging everything above a single similarity score treats that case the same as an obvious duplicate, and the consequence is a destroyed record, not a false alarm: the two people's activity history merges into one, and there's no clean way to un-merge it.
Account-level merges carry more consequence than person-level merges
A person-level merge risk is bounded: wrong-merge damage is largely activity history and identity. An Account-level merge risk is not bounded the same way, because an Account carries Opportunity and contract history. Merging two Accounts that shouldn't have been merged can misattribute closed revenue, break a contract timeline, or silently combine two customers' billing history.
Keep Account merges review-only, even for pairs your matching rule scores as high-confidence. Person-level merges can safely auto-run above a confidence threshold once that threshold is proven reliable. Account-level merges shouldn't, regardless of confidence score, because the cost of being wrong is categorically higher than the cost of one more human review click.
Protect records a merge could quietly harm
Before any merge runs, whether auto-merge or reviewed, check whether either record meets a protection condition. A protected record can still be merged, but never silently, and never as a side effect of a batch job's default behavior.
| Protection condition | Why it matters |
|---|---|
| Open Opportunity | A merge can orphan or misattribute an active deal |
| Active Customer Success relationship | A merge can sever a live support or renewal thread |
| Recent marketing engagement | A merge can discard evidence a lifecycle decision depends on |
| Closed-won customer | A merge risk here touches billing and contract history, not just a CRM record |
A merge involving a protected record should route to explicit review with the protection reason stated, even if the match confidence would otherwise clear the auto-merge bar.
Survivorship: decide per field family, not per record
When a merge does run, "keep the newer record" is not a survivorship rule; it's an absence of one. Different field families need different rules:
| Field family | Survivorship rule | Why |
|---|---|---|
| Contact info (email, phone, title) | Most recently verified wins | Verification, not recency of edit, is the trust signal |
| Relationship history (activities, notes, associations) | Union: preserve all, don't drop either record's history | History from both records is real; discarding one side loses evidence |
| Practitioner-owned assessments | Manual review required | An automated survivorship rule shouldn't silently pick a winner for a human judgment field |
| System-derived scores | Higher-authority source wins, or recalculate post-merge | A stale calculated field from either side may already be wrong |
Log which values were merged, which won, and why, so a bad merge can be traced back to the rule that produced it rather than discovered by accident weeks later.
GTM Lab: the pair that looks like one person and isn't
GTM Lab is a fictional B2B software company. Two records in its pipeline for target account Ferrow Industrial: Marcus Webb and Marcus Webber, both showing the same company domain and a similar (but not identical) title. A rules-only fuzzy matcher scores this pair at moderate-to-high similarity: same first name, near-match surname, same employer.
Run it through a two-outcome model and the pair auto-merges. Run it through the three-outcome model above and the pair routes to review instead, holding both records with the match evidence attached. Manual review turns up what the matcher couldn't see: Marcus Webb is a director-level buyer already in an active evaluation; Marcus Webber is a separate engineering contact who was never on that call. The review step is the entire reason this doesn't become one merged, and wrong, record.
Separately, GTM Lab's existing Contact Priya Shah (introduced in the 1a lifecycle guides, now with an open expansion Opportunity at Acme Manufacturing) is proposed for a merge against a near-duplicate record, Rina Fields, that a bulk import created by copying Priya's phone number and email domain onto a new contact. Priya Shah's open Opportunity trips the protected-record check. The merge doesn't auto-run even though the match confidence is high; it routes to review with the protection reason (open Opportunity) attached, which is exactly the outcome the protection rule exists to produce.
This is a worked example. The specific names, thresholds, and confidence scores are fictional; the pattern (an adjudication tier between auto-merge and no-match, and a protection check that runs before any merge) is what should carry into a real duplicate-detection design.
Salesforce and HubSpot: what changes, what doesn't
Salesforce's duplicate and matching rules can flag potential duplicates at save time and support custom matching logic, and Lead conversion has its own duplicate-merge considerations worth reading before configuring a Lead-merge process specifically. Neither gives you an adjudication tier or a survivorship policy by default; those are yours to design on top of the platform's matching primitives.
HubSpot's merge tools support manual and managed dedupe review across Contacts, Companies, and Deals. Its merge behavior determines which values are retained by default; verify current behavior before assuming it matches the survivorship rule your team has designed, and override the default where it doesn't.
Duplicate detection checklist
- Match signals are classified by trust level, not treated as equally reliable.
- Three outcomes exist: auto-merge, human review, no match. Not two.
- The auto-merge threshold is reserved for exact-match-backed or otherwise proven-reliable pairs.
- Account-level merges are review-only regardless of confidence score.
- A protection check (open Opportunity, active CS relationship, recent marketing engagement, closed-won) runs before every merge, auto or reviewed.
- Survivorship rules are defined per field family, not as one blanket "newer wins" rule.
- Merge evidence (match signals, confidence, adjudication reasoning, which values won) is retained and traceable.
- A protected record's merge is never silent, even when it eventually happens.
Where this connects
Survivorship rules for automated or enrichment-sourced fields specifically are covered in conflict resolution and overwrite policy, which builds on the source, authority, and freshness framework in the CRM field dictionary. The audit baseline this detection work feeds is defined in CRM data quality audit.
Related guides
Get the next guide
New guides and the occasional note on GTM tooling. Don't worry, I won't drop you into a three-month nurture.