Before merging two CRM leads, confirm that they represent the same person, choose the record that should survive, map every field and activity that must be retained, and check what the merge will trigger downstream. A shared name or company is only a reason to investigate. It is not enough evidence to merge. When identity remains uncertain, keep the records separate and flag them for later review.
Start with identity, not record similarity
Duplicate detection and duplicate resolution are different jobs. Detection produces candidates; review determines whether the records refer to one real person. Salesforce describes the same separation in its tooling: matching rules identify potential duplicates, while duplicate rules determine how those matches are handled. Whatever CRM you use, treat an automated match as an alert rather than a verdict.
Rank evidence by how specifically it identifies a person. An exact normalized business email is usually stronger than an exact full name. A direct telephone number combined with the same employer can be persuasive. Name and company alone are weak because colleagues may share names, companies have several entities, and contacts change jobs.
Normalize before comparing. Lowercase email domains, remove harmless telephone formatting, recognize company-domain aliases, and compare both current and historical values. Do not erase the original values during review; normalization should help comparison, not rewrite source data prematurely.
Classify the pair before taking action
A practical review needs more than “duplicate” and “not duplicate.” Assign each candidate pair to one of four outcomes:
| Outcome | Evidence pattern | Action |
|---|---|---|
| Confirmed duplicate | Strong identifiers agree and no material facts conflict | Merge after preservation and automation checks |
| Related, not duplicate | Same company, household, assistant relationship, or shared inbox; different people | Keep separate and link through account or relationship fields |
| Conflicting identity | An exact identifier matches, but names, regions, or histories materially disagree | Pause and investigate the source or possible reused data |
| Insufficient evidence | Only weak attributes match | Keep separate and schedule review when better data arrives |
For example, “Alex Lee” at the same multinational company may be two employees. Conversely, two records with different surnames may belong to one person—for example, after a name change—if a stable business email, direct number, and activity history also align. The classification must follow the evidence, not the visual similarity of the rows.
Choose the master record deliberately
The oldest record should not automatically win. Neither should the newest. Select the surviving record according to a documented priority order: valid consent and suppression state, active ownership, open opportunity relationships, verified contact details, complete attribution, and reliable source provenance.
Then decide field by field. Keep the verified telephone number over an unverified one; preserve a current title while retaining the previous title in history if useful; choose the most precise acquisition source rather than whichever value sits on the master. Never overwrite an unsubscribe, do-not-call status, or lawful-basis record with a less restrictive value merely because it is newer.
Ownership also needs an explicit rule. If one record has an active opportunity and the other belongs to a newly assigned representative, determine ownership before merging so the CRM does not silently route the combined history to the wrong person. Clear pipeline-stage definitions make these decisions easier when duplicate records sit at different stages.
Protect history, attribution, and linked objects
A merge can alter more than visible contact fields. Review emails, calls, meetings, notes, tasks, campaign membership, form submissions, lead-source details, scoring events, opportunities, quotes, tickets, custom objects, attachments, and consent logs. Determine whether your CRM moves, combines, ignores, or deletes each object type.
Pay particular attention to attribution. Suppose one record came from a webinar and another from a later demo request. Choosing a single “lead source” may erase the distinction between first touch and conversion touch. Preserve both in appropriate fields or campaign history rather than forcing one event to replace the other.
Also trace where the duplicate originated. Repeated form submissions, an integration using create instead of update, inconsistent email normalization, or imports without stable external IDs will recreate the problem after cleanup. If form traffic is involved, use the checks in the web-form-to-CRM diagnostic process to examine field mapping and record creation.
Run a pre-merge impact check
Before committing the merge, list every automation that may react to the surviving record or moved data. This can include assignment rules, lead scoring, nurture enrollment, sales sequences, alerts, enrichment jobs, synchronization with marketing platforms, territory logic, and customer lifecycle updates.
A safe operating pattern is to test the procedure in a sandbox or with low-risk internal records, export the candidate records, and capture their IDs. For high-volume work, process a small batch first and reconcile the results before continuing. If your CRM offers no reliable undo function, the export and audit log become essential recovery references.
Do not let the merge create a false “new lead” signal. Suppress unnecessary notifications and sequence enrollment where possible, then verify that the surviving record has not been rescored, reassigned, or moved to an inappropriate lifecycle stage.
Use this reviewer checklist
- Identity: Is the available identifying evidence strong enough, with no serious contradiction?
- Normalization: Were email, telephone, company, and domain values compared in normalized form?
- Relationship check: Could these be colleagues, relatives, assistants, or users of a shared inbox?
- Master selection: Is the surviving record chosen by policy rather than age or convenience?
- Field map: Is the winning value documented for every important field?
- Restrictions: Will all opt-outs, consent evidence, and communication restrictions survive?
- History: Will activities, campaigns, forms, notes, files, and attribution remain accessible?
- Revenue objects: Have opportunities, quotes, orders, or subscriptions been checked?
- Ownership: Is the post-merge owner correct and aware of the change?
- Automation: Could the merge trigger routing, scoring, sequences, or lifecycle changes?
- Recovery: Are original IDs, exports, and the reviewer’s decision recorded?
- Prevention: Has the process or integration that created the duplicate been identified?
Document the decision and prevent recurrence
Record the candidate IDs, evidence reviewed, classification, master-record choice, important field decisions, reviewer, and date. For a non-merge, add a reason such as “same company, different person” so the pair does not repeatedly return to an undifferentiated queue.
Use review outcomes to improve detection. Too many false positives may mean the matching criteria are broad; missed duplicates may reveal unnormalized telephone numbers, email aliases, or absent external IDs. Separate automatic handling from manual handling: if automated merging is permitted at all, limit it to narrowly defined cases that have been tested against your CRM’s retention, automation, and recovery behavior; send ambiguous pairs to a reviewer.
The safest rule is simple: merging is an identity and data-governance decision, not a cosmetic cleanup task. When evidence is strong, preserve the right record and its full context. When evidence is weak, uncertainty is cheaper than an irreversible merge.
