TL;DR
- A large merge can change owners, record IDs, list memberships and automations.
- Open a sample of merged records, including the largest sets and key accounts.
- Compare record counts and key reports with the numbers taken before the merge.
- Check every integration or spreadsheet that stores record IDs from the CRM.
- Dedupely records every merge with original and winning values, so each check has a reference.
A large merge can finish in minutes. Whether it went well takes a little longer to know, because some effects only show up in records, reports and tools outside the CRM.
A short check right after the merge catches problems while they're small. It also tells you whether your rules are ready for the next round.
This post is that check. You'll see why a merge needs one, a checklist of what to look at, and what to do if something looks wrong. Preparing a backup is a separate step, covered in our guide on backing up your CRM before a large merge.
Why a large merge needs its own check
A merge decides which record survives, which value wins in each field and where associations go. Each of those decisions can ripple into other parts of the CRM.
HubSpot creates a new record ID and unenrolls both records from active workflows by default. Its Primary ID Preservation public beta keeps the primary ID and primary workflow enrollment; the secondary is unenrolled. The secondary record leaves static segments, and the primary's property values generally win, with documented exceptions. Check the behavior for your account and merge method.
As of October 2026, from HubSpot's knowledge base: Merge records.
Your monthly routine looks at what's new. This check is different: it looks at what one merge changed. Our CRM record maintenance checklist covers the routine.
A checklist for after a large merge
Work through these in order. The first checks are inside the CRM, and the later ones reach the tools around it.
1. Open a sample of merged records
Pick a few random merges and a few chosen ones: the largest duplicate sets, key accounts and any edge cases you worried about. Compare each result with the original records.
Ask the simplest question first: is this a merge you'd have made by hand? If not, note which criteria found the match.
2. Check owners and the fields teams rely on
Owner, lifecycle or lead stage and email opt-out often cause trouble when the wrong value wins. Check them on every record in your sample.
A changed owner moves an account to another rep. A lost opt-out means emailing someone who asked you to stop.
3. Check associations and activity
Open the merged records' related deals, companies and contacts. Each should link to the surviving record, with notes, calls and tasks in its history.
Also check the other direction. A contact merged under the wrong company now carries its deals to the wrong account.
4. Compare counts and reports
The drop in records should roughly match the extra records in the sets you merged. A much larger drop points to a rule that grouped more than you expected.
Then check the reports leadership reads, like customer counts and pipeline. Changes there should trace back to the merge. Our post on duplicate rate and other CRM accuracy metrics covers which numbers to track over time.
5. Check automations and lists
Look at workflows, sequences and lists that used the merged records. Some records may have left an automation they should still be in, or joined one they shouldn't.
Re-enroll records where needed, and check that list sizes make sense.
6. Check integrations and anything that stores record IDs
Billing systems, support tools, data warehouses and shared spreadsheets often store CRM record IDs. After a merge, some of those IDs may point to records that no longer exist.
Check a few merged records in each connected tool. Our post on deduplication across connected tools covers how syncs and integrations interact with merges.
7. Watch for new duplicates
Forms, imports and integrations keep running after the merge. If a connected tool still holds the old record, it may create it again.
Run the same searches a few days later. New duplicates of records you just merged usually point to a source worth fixing.
8. Tell the team what changed
Share what merged, what reps may notice and where to report problems. People who use the records every day find issues a sample can miss.
Post-merge checklist at a glance
| Check | What to look at | Sign of a problem |
|---|---|---|
| Sample of merges | Random merges, largest sets, key accounts | A merge you wouldn't have made by hand |
| Key fields | Owner, stage, email opt-out | An owner or opt-out that changed unexpectedly |
| Associations | Deals, companies, contacts, activity | Records linked to the wrong account |
| Counts and reports | Records per object, customer counts, pipeline | A drop much larger than the extra records merged |
| Automations and lists | Workflows, sequences, list sizes | Records missing from an automation they need |
| Integrations | Tools and spreadsheets that store record IDs | IDs that point to records that no longer exist |
| New duplicates | The same searches, a few days later | Merged records created again by a source |
| Team feedback | Questions from reps and managers | Repeated reports about the same kind of record |
If something looks wrong
Hold the next round until you know the cause. Find which search or criteria produced the wrong merges, and how many merges share it.
Many CRM merges cannot be undone. Use the backup and merge history to plan recovery with the CRM owner or vendor. Recreating field values alone may not restore IDs, activities, associations or downstream links. Resolve the affected records before resuming the rule.
When you're certain two records aren't duplicates, reject the match so it doesn't come back. What counts as a duplicate is case by case, and a wrong merge often shows where your team's definition and your rules differ.
How Dedupely helps you check a large merge
Every duplicate search in Dedupely shows the number of matches and the number of records in them, which gives you your "before" numbers. Every merge is then recorded with the original records, the winning values, the result and a link to the record in your CRM. When a merge needs fixing, you can filter merges by date and export their original values as a CSV.
Check before the next round
A large merge reaches past the records it combines. Owners, associations, reports, automations and connected tools can all change, and a short check finds problems while they're still small.
Take your numbers before the merge, look at a sample after it and follow the changes out to the tools around the CRM. When the check comes back clean, your rules are ready for the next round.
Frequently asked questions
What should you check after merging CRM duplicates?
Check a sample of merged records, especially owners, stages and email opt-outs. Then confirm associations and activity moved to the surviving record. Compare record counts and key reports with your numbers from before the merge, and check automations, lists and any integration that stores record IDs.
Why did my reports change after merging duplicates?
Because duplicates stopped being counted. A customer stored three times counted three times before the merge and once after it. If the drop is much larger than the extra records you merged, check whether a search grouped records that weren't duplicates.
Do merged records stay in workflows?
It depends on the CRM. In HubSpot, as of October 2026, merged records can be unenrolled from workflows, so check the automations that used them. In any CRM, look at workflows, sequences and lists after a large merge, and re-enroll records where needed.
Can a merge break CRM integrations?
It can, when a connected tool stores CRM record IDs. A merge can remove or change the IDs of the records involved, so the tool may point to a record that no longer exists. Check a few merged records in each connected tool after a large merge.
How do you fix a bad merge in a CRM?
Pause the affected search and identify the incorrect matches. Use backups and merge history to plan recovery with the CRM owner or vendor; re-entering fields may not restore the original IDs or linked history. Test revised criteria on a reviewed sample before resuming, and reject confirmed false matches.










