CRM Duplicate Records: Designing a Merge Workflow

How should a CRM workflow handle duplicate records?

A duplicate record is more than an extra row. It splits the history of a customer across records, so automated tools that read the CRM can miss context, mix notes, or act on the wrong account. The workflow needs a way to find duplicates, decide which are safe to merge, and keep a record of the change.

Start with data the team can verify. Email, domain, and phone are concrete starting points. Fuzzy matching on names alone produces false positives that are hard to audit.

Define the matching rules first

Write down what counts as the same customer before designing the merge step. An exact email match is strong evidence. A shared domain may point to separate contacts at the same company, which is a different problem.

Store the match evidence with the candidate pair: which fields matched, what the values were, and why the pair was flagged. A reviewer should be able to see the reasoning behind a suggestion.

The CRM automation and data hygiene guide covers the record quality work that comes before matching.

Use confidence levels instead of a single score

A raw similarity score is hard to review. Confidence levels with clear definitions are easier to act on. An exact match on a unique identifier can be treated differently from a partial name and address match.

Define what happens at each level:

• High confidence: merge automatically when no field conflicts.
• Medium confidence: send the pair to a review queue for a person to confirm.
• Low confidence: leave the records separate and log the suggestion for later.

Keep the definitions simple enough that an operator can explain them.

Resolve conflicts with explicit precedence

When two records disagree, the merge should not guess. Define field precedence in advance: which source wins, whether the most recent value wins, and which fields require manual review.

Record the discarded values. A merge that silently drops an old phone number or a previous owner makes the change hard to undo.

Show a merge preview before writing

Before the workflow writes to the CRM, show what the merged record will look like. List the fields that change, the values that get discarded, and the source of each winning value.

For medium-confidence pairs, this preview belongs in the review queue. The reviewer should be able to confirm the match, edit the merged values, or reject the pair without working around the system.

Keep an audit trail of the merge

Store the original record identifiers, the merge time, the person or rule that approved it, and the discarded values. The audit trail lets the team undo a bad merge or explain it later.

New merges should be visible in the same place the team reviews other changes. The AI workflow exception handling guide describes how to keep the review path consistent.

Stop new duplicates at intake

Matching cleans up existing records, but it does not stop new ones. Check for duplicates when a record is created, not only during periodic sweeps. Required fields and input validation prevent the obvious cases.

Keep the periodic re-scan as a safety net. Sources change and records get merged, so the workflow should re-check the records on a schedule and surface new candidates.

What belongs in a merge workflow brief?

Document the matching rules, confidence levels, field precedence, review queue, and audit trail. Name the owner of merge decisions and the person who can reverse a bad merge.

Include test cases: the same email with different names, two contacts at the same company, a record updated after the pair was flagged, and a merge where both sides claim different owners. Each case should show what the reviewer sees and what the CRM contains afterward.