If sales keeps reviewing the same contacts, deduplication may remove repeated work. But fewer rows do not prove the cleanup is correct: a mistaken merge can combine two customers’ owners, opportunities and histories. I start by agreeing what “the same lead” means for that operation.
This guide focuses on record identity and quality before delivery. For the full journey from extraction to the destination write, see the scraping to CRM pipeline guide.
Duplicate, spam and incomplete are different decisions
A duplicate represents an entity already known to the system. An out-of-segment record may be valid but irrelevant to your operation. A missing phone means incomplete information; it does not prove the business is fake. A generic email address alone does not make a contact spam either.
I separate the identity decision from the quality decision: “same company” and “awaiting verification” can both apply. Every rejection needs an observable reason. Uncertain cases stay in review, with agreed rules for what evidence to retain, for how long and who can access it.
Define the entity before comparing names
A company, branch, person and sales opportunity need different identities. Two branches may share a domain and switchboard. A broker may publish listings for several businesses. A match helps find candidates; it does not necessarily justify merging them.
I retain the original value alongside a normalized comparison value. A phone’s country must be known; empty fields do not count as matches. Normalizing spacing or formatting must not remove meaningful parts of an email, address or name. Keep the source, source ID, capture time and rule version.
What to merge, keep separate or review
Consider a hypothetical importer receiving branch listings from several approved sources. These proposed decisions need testing against a sample labelled by operations; they are not universal thresholds.
| Situation | Proposed decision | Check |
|---|---|---|
| Same source and stable ID | Update the existing source record. | Confirm the provider does not recycle IDs; this alone does not resolve identity across sources. |
| Same domain, different branches | Keep branches separate. | Link them to a parent company only where evidence supports it. |
| Same phone, different names | Send to review. | Check for a shared switchboard, broker or reassigned number. |
| Similar name, incomplete address | Do not merge automatically. | Seek more evidence or leave the case unresolved. |
| Confirmed identity, conflicting values | Resolve fields before applying changes. | Keep the verified correction and record the incoming proposal. |
A score ranks candidates; it is neither a proven probability nor permission to merge. If A resembles B and B resembles C, I do not assume that A, B and C are one entity. Review contradictions across the whole group. Salesforce explains duplicates and false matches; the actual rule depends on the business data model.
Which information survives a merge?
Before changing the CRM, I prepare a preview showing affected records, the resulting entity, proposed field changes and associations that would move. We agree who owns each field. A newer import should not silently replace a phone verified by sales or change an opportunity’s owner.
I retain the decision, rule, reviewer and mapping between previous and current IDs within the agreed retention policy. This helps investigate mistakes; it does not guarantee reversal. HubSpot documents that merged records cannot be unmerged. Check the consequences in your actual CRM before enabling automatic merges; a prior CSV does not necessarily restore associations, activities or external effects.
Human review needs a clear outcome
The queue should show original values, differences and the reason for a proposed match. A reviewer can confirm identity, keep entities separate or request more information. “Unresolved” does not mean approved. If nobody can review the backlog, the workflow must hold pending cases.
I also retain “do not merge” decisions so the same pair is not proposed on every import unless relevant evidence changes. Assign an owner and monitor queue age. An identity decision does not itself authorize a sales message.
How to accept a deduplication pilot
First I run rules without writing changes and compare their proposals against a sample reviewed by the team. Reserve evaluation examples that were not used to tune the rules. For the hypothetical importer, I would propose these checks:
- Repeat import: importing the same source record retains its identity and creates no extra entity.
- Branches: two locations sharing a domain remain separate.
- Empty fields: two absent phone numbers do not count as a match.
- Contradiction: a shared phone with incompatible addresses reaches review.
- Human correction: a new capture preserves the verified value and displays the conflict.
- Mistaken merge: the team can identify changes and rehearse the available recovery, recording what cannot be restored.
Measure false matches among reviewed proposals, known duplicates that were missed and review effort by source. Agree thresholds based on the damage of an incorrect merge and the team’s capacity. An error-free sample does not prove perfect accuracy across the database.
Quality needs maintenance after cleanup
A source or parser change can alter names, IDs or addresses and trigger false matches. Version rules and review a sample when inputs change. The scraper maintenance guide covers that extraction layer.
The Adslyfy case shows execution status and operational evidence in ad monitoring. It is a traceability reference, not a CRM deduplication case or evidence of a matching accuracy rate.
A correct identity can still cause repeated work when delivery fails. Check retries and unknown outcomes separately using the CRM pipeline acceptance tests.
What to commission and what a proposal should include
If your CRM’s built-in features cover the entity, matching rules and review process, start by configuring and testing them. Custom development makes sense when you need identity resolution across sources, your own policies or an integrated review queue. That work fits my API and CRM integration services.
Ask for the entity model, versioned rules, evaluation sample, change preview, recovery limits and maintenance owner. Separate implementation, human review and operation when comparing software proposals. If teams and suppliers lack a common technical direction, fractional CTO support may fit.
Next step: review your difficult cases
To assess the scope, tell me where duplicates appear and prepare synthetic or anonymized examples of a genuine duplicate, similar records that must stay separate and a manual correction. I can review the rules and systems with you and define what a first delivery should demonstrate.