Put an Approval Gate Before Any CRM Duplicate Merge

Not every similar record should be merged. Decide which entity types are in scope, such as company accounts or contacts, and which are explicitly out. Subsidiaries, franchise locations, and household contacts often share a domain or a phone number while remaining separate commercial entities.

Write a merge policy with three outcomes: merge, keep separate with a relationship link, and defer for more evidence. The third outcome matters most: it lets an analyst stop when the record is ambiguous instead of forcing a bad choice.

State who may request a merge, who may approve one, and which systems are affected. A CRM merge may leave the billing system, the marketing platform, and the support desk untouched, which creates a new inconsistency even when the CRM looks clean.

A shared domain is weak evidence in a world of shared office space and parent companies. Build a small scoring model with corroboration requirements. One strong identifier can carry a merge, while several weak signals should route to review rather than auto-approve.

Record the score and the matched fields on the merge request. The score is not a truth claim. It is a summary of the evidence a reviewer can inspect. When the score and the reviewer disagree, the reviewer wins and the reason is captured.

The survivor is the record that keeps its identifier, owner, and history. Choose it before changing any field, because merge tools often make that choice implicitly and permanently. Prefer the record with the longest activity history, the active owner, and the open opportunities, not the most recently created one.

Build a field-level survivorship plan. For each field, decide whether the survivor keeps its value, takes the losing record's value, or is set manually. Critical fields such as legal name, billing address, tax identifier, and account owner should be manual by default. Descriptive fields such as industry or employee band can follow a declared rule.

Capture the plan in the request. A reviewer should be able to see the proposed values before the merge runs, not after. If the tool does not support a preview, export both records to a staging sheet and review them side by side.

Consent and opt-out status need special handling. If either record carries a withdrawal, a do-not-contact flag, or a channel-specific restriction, the merged record must inherit the most restrictive state. The NIST Privacy Framework treats data handling as a risk management concern, and a merge that quietly drops an opt-out is exactly the kind of operational risk it describes.

Activity history should move with the record, not disappear. Check that calls, meetings, notes, campaign memberships, and support tickets are re-parented to the survivor. Then check open opportunities, quotes, and contracts for owner changes or broken lookups.

Revenue is the part that finance will notice. List every open opportunity on both records, its amount, stage, and close date. If the merge would combine two live opportunities for the same buyer, stop and let the sales manager decide which one represents the deal.

The person who prepares a merge should not be the only person who approves it. A second reviewer checks the evidence, the survivor choice, the field plan, and the revenue impact. For low-risk contact merges the review can be a sampled check, but account merges with open pipeline deserve a named approver every time.

Store a merge record with the request identifier, both source identifiers, the survivor, the score and matched fields, the field decisions, the reviewer, the approval timestamp, and the tool used. Export the losing record before the merge. The export is the rollback path when someone discovers a missing contract or a lost consent flag.

Keep the record for as long as the account exists. Questions arrive months later, when a customer disputes their history or a new administrator inherits the database.

Some records should stay separate even when they look identical. Franchisees, dealer groups, buying consortiums, and shared service entities may use one domain and one procurement contact while operating as distinct customers. Merging them destroys territory credit and reporting.

Create a permanent exception list with a reason code and a review date. Link the records with a "related to" relationship so reporting can see the connection without collapsing the entities. Note the shared contact and who owns the relationship.

Once a month, pull a sample of completed merges and check four things: the survivor was correct, the field values matched the plan, consent survived, and open revenue was not lost. Ten to twenty records drawn across preparers is enough to reveal patterns.

Publish the reversal count and the reasons. If the same signal produces most reversals, lower its weight or require another corroborating field.

For the candidate review step, see routing duplicate lead candidates; to review a merge queue, book a free consultation. Close the loop with the representatives who requested the merges. They see the downstream effect first, and their corrections are the cheapest source of rule improvements. A merge gate that never changes its rules is just a slower version of the old cleanup.