Why matching and merging are separate decisions

"Dedupe and merge" sounds like one step. In practice, it's two decisions: which records are the same, and what the final record should look like.

When teams treat them as one, problems are hard to trace. A wrong owner after a merge gets blamed on the match, or a good match gets rejected because the merged record looked wrong.

In this post, you'll see what each decision controls, what "merge/purge" means and what goes wrong when the two blur. You'll also see how to test each one on its own before you merge in bulk.

Matching finds the set, merging decides the result

Matching compares records and groups the ones you consider duplicates into a set. It answers one question: are these the same customer, company or deal?

Merging takes a set and turns it into one record. It answers a different question: what should that record keep?

What "merge/purge" means

Merge/purge is an older term from mailing lists. Teams combined lists, found records that referred to the same person or address and kept one entry.

The idea carries over to CRMs. Matching finds the duplicates, merging combines them into one record, and the purge is the removal of the extra records.

In a CRM, the purge happens as part of the merge. The extra records are deleted or archived, depending on the CRM, and their activity and associations usually move to the surviving record.

The matching decision

Matching is about evidence. You choose the fields that identify a record, like email for contacts or domain for companies, and decide how strictly each one must match.

What counts as a duplicate is case by case. What one team considers a duplicate, another may not, like two branches that share a domain. That's why the same records can need different criteria in different CRMs.

Our posts on how duplicate matching works and which fields to match on cover match types and fields in detail.

The merging decision

Merging is about the result. Once you agree that records belong together, you still have to decide what survives.

Which record survives

One record in the set becomes the primary. Common choices are the oldest record, the newest, the last updated or the one with the most data.

The choice matters because the primary record often keeps its record ID and some of its values by default. In some CRMs, a merge creates a new record ID instead.

Which value wins in each field

Each field can follow its own rule. The phone number might come from the most recent record, the owner from the oldest and the lifecycle stage from the most advanced.

Fields that hold several values, like tags, can sometimes combine values from every record. Single-value fields need one winner.

What happens to related records

Activities, deals and other associations usually move to the surviving record. Check how your CRM handles them, since that's often what people miss most when a merge goes wrong. Our post on merging CRM records without losing data goes deeper.

What goes wrong when the two blur

Many cleanup mistakes come from using one decision to fix the other. Three come up often.

Blaming the match for a bad merge

Two records for the same company merge, and the account ends up with the wrong owner. The match was right. The owner rule was wrong.

Tightening the match here would hide real duplicates. Fixing the owner rule solves the problem for every future merge.

Rejecting good matches

When a merged record looks wrong, it's tempting to reject that kind of match. But a rejected match stays out of future searches, and the duplicates stay in the CRM.

Reject a match only when you're certain the records aren't duplicates. If the problem was the result, change the merge rules instead.

Trusting every match the same way

An exact email match and a match on similar names aren't equally certain. They can share merge rules, but they deserve different handling.

Merge the obvious duplicates, like exact matches on email or domain, in bulk. Send looser matches to review, where someone checks each set before it merges.

Test each decision on its own

Test the match first. Read a sample of matched sets and ask one question: are these the same record? Adjust the criteria until the answer is yes for the sets you'd merge.

Then test the merge. Preview the result for a sample, including a few edge cases, and check the fields that matter most, like owner, stage and email opt-out.

Once both hold up, you can merge in bulk. When your rules are tested, you can merge new duplicates you're certain of, like exact email matches, automatically on a schedule.

Two decisions, one clean record

Matching and merging answer different questions. Matching decides whether records are the same; merging decides what the final record keeps. Merge/purge is the older name for both, plus removing the extras.

Keeping the decisions apart makes problems easier to fix. A wrong group means changing the criteria, and a wrong value means changing the merge rule. Test each one on a sample, and bulk merges become far less risky.

Frequently asked questions