Deduplication has two decisions: whether records describe the same entity, and which values and relationships should survive. A matching email or company name can suggest a candidate. It should not silently authorize a merge.
Define the entity and the matching rule
An account, contact, lead, site, and billing entity are different objects. Two branches can share a company name while needing separate delivery and billing records. Two people can share a team email address. Decide what each CRM table represents before declaring fields unique.
Microsoft Dataverse distinguishes detecting potential duplicates from merging them. Its merge interface lets users choose a primary record and resolve conflicting fields; merge support and behavior are limited to specified record types. Confirm those details in the CRM you actually use. Microsoft’s duplicate detection and merge documentation.
Normalize comparisons without rewriting identity
Trim surrounding whitespace and apply an agreed case rule to comparison keys while preserving source values. Standardize phone formatting only with enough country context. Do not remove email punctuation or shorten company names on the assumption that the result identifies the same person or legal entity.
Use strong identifiers where your system has them, such as an authoritative external account code. Check whether the identifier is genuinely unique in the relevant system and entity type. A shared domain or approximate name is supporting evidence, not a unique key.
Work through a fictional candidate set
| Candidate pair | Evidence | Decision |
|---|---|---|
| Accounts A-41 and A-89 | Same confirmed external account code; different display names | Review as a likely duplicate |
| Contacts C-12 and C-56 | Different people using billing@harbor-example.invalid | Retain both; shared mailbox is not person identity |
| Sites S-3 and S-8 | Same company; different delivery addresses | Retain separately under the agreed site model |
The account pair still needs relationship and value checks. “Likely duplicate” describes the matching evidence. It does not establish that merging will preserve the operational history correctly.
Create a field-survival worksheet
For each conflict, record the field, values in both records, preferred value, authoritative source, verification date, and decision owner. Use a policy per field. The newest record should not automatically win if it contains an empty phone number or an unverified billing address.
A candidate is not permission to merge.
- Find
- Propose matching identities
- Compare
- Choose surviving fields
- Review
- Check relationships and impact
- Merge
- Authorize and record the result
View data
| Evidence | Meaning |
|---|---|
| Find | Propose matching identities |
| Compare | Choose surviving fields |
| Review | Check relationships and impact |
| Merge | Authorize and record the result |
Illustrative operating model. Apply your organization’s controls.
Download image- Owner: confirm the team responsible after the merge.
- Contact details: keep the verified current value and retain relevant history.
- Consent or communication preferences: escalate conflicting values to the responsible policy owner.
- External identifiers: preserve aliases needed by connected systems.
- Related work: inspect open tickets, orders, activities, and attachments.
Test what a merge changes downstream
Check whether connected systems store the secondary record ID. Define an alias mapping or update route so future messages still find the retained record. Test relationship counts before and after a merge using the CRM’s supported operation. Do not simulate merging by deleting a row and copying a few visible fields.
Keep a decision log containing candidate IDs, evidence, primary record, field decisions, reviewer, operation result, and any downstream repairs. Confirm the available recovery behavior before executing a merge; do not promise reversibility that the platform cannot provide.
Prevent the next duplicate at entry
Run candidate checks where new records are created or imported, using the same identity policy. Keep uncertain cases in a queue rather than forcing either a merge or a fresh record. Measure false matches and duplicates missed, because an aggressive rule can make the database smaller while making it less correct. The readiness tool helps surface gaps in identifiers, ownership, and integration access before a cleanup begins.