Salesforce Duplicate Management: How to Merge Accounts Safely

Key takeaways

• Match accounts on a clean root domain first, then name and address. Name alone merges companies that only look alike.
• Decide survivorship before you merge anything: which record wins, and which field values carry over from the losers.
• Merge in small, logged batches, tested in a sandbox. A merge you can't trace is a merge you can't undo.

A rep opens an account and sees three contacts. Another rep opens the same company and sees four different ones. Both think they own it. Marketing is emailing a fifth person who left last year.

That’s what duplicates do in Salesforce. This guide shows how to find them, how to decide which record survives, and how to merge without losing history.

Why duplicates cost more than they look

One duplicate account isn’t a crisis. Thousands of them quietly break things: lead-to-account matching assigns to the wrong owner, territory reports double count, and activity history gets split across records so nobody sees the full relationship.

It gets worse once you add automation. A scoring model or an AI agent that reads Salesforce will treat each duplicate as a separate company. Clean up first, then automate. Our CRM data hygiene checklist covers the wider audit this fits into.

How Salesforce finds duplicates

Salesforce handles this with two pieces. A matching rule defines when two records count as alike. A duplicate rule decides what happens when they do: block the save, allow it with a warning, or report it.

The built-in standard rules are a reasonable start. For accounts, they lean on name and location, and that’s where most of the false matches and misses come from.

Match on domain first

Names are messy. “Acme Inc.”, “ACME Incorporated” and “Acme Industries” could be one company or three. A root domain is much stronger evidence.

So build your matching logic in layers:

1. Exact root domain. Strip protocols, www and paths, and lowercase everything. https://www.acme.com/about becomes acme.com.
2. Fuzzy name plus country. Only where the domain is missing, and flag for review rather than merging automatically.
3. Address or phone as tiebreakers, never as the sole reason to merge.

One caution: free email domains and shared hosts (a Gmail address, a franchise platform) will create false matches. Exclude them from domain matching.

Decide survivorship before you merge

Survivorship is the rule for which record stays and what happens to the data on the others. Skip this and the person clicking “merge” decides record by record, differently each time.

Question	A sensible default
Which record is the master?	The one with the most recent real activity, then the most open opportunities
Which created date is kept?	The oldest, so history reads correctly
Which owner wins?	The owner of the master, unless that user is inactive
What about conflicting field values?	Prefer non-blank, then most recently updated
Child records (contacts, opps, cases)?	All re-parented to the master

Write these down and get sales and RevOps to agree. Ten minutes on this saves a week of arguments after the first bad merge.

Merge in reversible batches

This is where cleanups go wrong. Merges are hard to undo, and a rule that looks fine on ten records can do damage on ten thousand.

Keep the low-confidence pairs out of automated batches. A fuzzy name match with no shared domain should go to a person.

An illustration: one domain, three accounts

Here’s an illustration (not a client story). Say a 40-person sales team has the company “Northwind Traders” in Salesforce three times: one from a trade show import, one created by a rep, one from a web form. All three share the domain northwind.example.

Under the rules above, the rep-created record has the most recent activity and an open opportunity, so it becomes the master. The import record’s phone number fills a blank field, the web-form contacts move across, and the other two accounts merge away. One company, one owner, one history.

Now the same thing, but the domains differ because one record has no website. That pair doesn’t merge automatically. It goes to a review queue.

Stop duplicates coming back

Cleanup without prevention lasts a quarter or two. Put these in place at the same time:

Imports are the usual culprit. A list from an event or a data vendor gets loaded as new records because nobody checked it against what’s already there. If you’re also tired of manual entry, see how to automate CRM data entry with AI.

When native tools are enough

Native duplicate rules and the merge tool are fine for a few hundred duplicates and a clear owner. Use them.

Past that, or with messy account hierarchies, multiple orgs or years of imports, it’s usually faster to run a proper matching and merge process with logging. Not because Salesforce can’t do it, but because clicking through merges at scale invites mistakes. If you’re also weighing platforms, our CRM comparison is worth a look.

The bottom line

Deduplication is a rules problem, not a tool problem. Match on domain, agree survivorship up front, merge in logged batches, and prevent new duplicates at the door. If your org has outgrown a weekend cleanup, talk to us about CRM data and enrichment.