Salesforce Duplicate Management: Rules, Matching & Merge Guide
A sales rep spends 20 minutes researching an account, crafting a personalized email, and hitting send. Thirty seconds later, a colleague on the same team pings them: "Hey, that's my account." They check Salesforce. Two Account records for the same company, one created by marketing from a webinar list, the other entered manually by sales. Different owners, different activity histories, different Contact records attached to each. Neither one has the full picture.
This happens constantly, and blaming rep discipline misses the cause. Salesforce duplicate management is a configuration problem. Without the right rules in place, duplicates enter your CRM faster than your team can find and merge them.
Salesforce provides matching rules, duplicate rules, and merge workflows. This guide shows how to configure them, review existing duplicate candidates, and test the create and edit paths that can produce new ones.
How Salesforce Duplicate Detection Works
Salesforce's duplicate management system has two layers, and you need to understand both to configure it correctly.
Matching Rules
A matching rule tells Salesforce how to compare records and determine if they're potential duplicates. It specifies which fields to compare, what matching method to use for each field, and how to combine those field-level comparisons into an overall match score.
Salesforce includes standard matching rules for Accounts, Contacts, and Leads. They're decent starting points but usually need customization.
Standard Account matching rule: Compares Account Name and Billing Street using fuzzy matching. This catches "Acme Corp" vs "Acme Corporation" but misses "Acme Inc." vs "ACME" because the fuzzy threshold isn't aggressive enough by default.
Standard Contact matching rule: Compares First Name, Last Name, Email, and Phone. Email is the strongest signal here. If two contacts have the same email address, they're almost certainly the same person.
Standard Lead matching rule: Compares Company, First Name, Last Name, Email, and Title. Similar logic to Contacts but applied to the Lead object.
Duplicate Rules
A duplicate rule defines what happens when a matching rule finds a potential duplicate. You have three action options:
- Allow (with alert): The user sees a warning that a potential duplicate exists but can still save the record. Most orgs default to this option.
- Block: The user cannot save the record if a match is found. Stricter, but prevents duplicates more effectively.
- Report: Salesforce silently logs the potential duplicate in a Duplicate Record Set for later review. No user-facing alert.
You can also control which channels the rule applies to: user interface, API, or both. This matters because a lot of duplicates enter through integrations and imports that bypass the UI entirely.
Common mistake: Setting duplicate rules to "Allow with alert" and wondering why duplicates keep appearing. Most reps click through the warning without reading it. If you're serious about prevention, use "Block" for clear-cut matches (same email) and "Allow with alert" for fuzzier matches (similar names).
Setting Up Matching Rules
Go to Setup, search for "Matching Rules," and either edit the standard rules or create custom ones. Custom rules give you more control over which fields to compare and how.
Recommended matching rules for Contacts
| Field | Matching Method | Why |
|---|---|---|
| Exact | Strongest dedup signal. Same email = same person, almost usually. | |
| First Name | Fuzzy: First Name | Handles "Bob" vs "Robert," "Mike" vs "Michael" |
| Last Name | Exact | Last names rarely have legitimate variations |
| Account Name | Fuzzy: Company Name | Catches contacts at the same company with different account spellings |
Create two matching rules for Contacts: one that matches on Email alone (high confidence), and one that matches on First Name + Last Name + Account Name (medium confidence). This lets you set different actions for each confidence level.
Recommended matching rules for Accounts
| Field | Matching Method | Why |
|---|---|---|
| Account Name | Fuzzy: Company Name | Core comparison. Handles suffix and abbreviation variations. |
| Website | Exact | If two accounts share a domain, they're likely the same company |
| Billing City | Exact | Disambiguates franchises and companies with generic names |
Account matching is trickier than Contact matching. Company names have endless variations. Adding Website as a matching field dramatically improves correctness because domains are unique. If you have a normalized company name field, use that instead of the raw Account Name for even better results.
Recommended matching rules for Leads
Mirror your Contact matching rules on the Lead object. Same email match, same name + company match. This catches duplicates both within Leads and across Leads and Contacts (cross-object matching).
Cross-object matching is particularly important. A new Lead comes in from a webinar, but that person already exists as a Contact on an Account. Without Lead-to-Contact matching, nobody knows. The Lead gets assigned to an SDR while the existing Account Owner has no idea their contact just raised their hand.
Configuring Duplicate Rules
Once your matching rules are active, create duplicate rules that reference them.
Recommended configuration
- Create a "Block" rule for exact email matches. If a Contact or Lead has the same email as an existing record, block the save. There's almost no legitimate reason to have two records with the same email address.
- Create an "Alert" rule for fuzzy name matches. Fuzzy matching catches more duplicates but also produces false positives. Let users override these with a click, but make sure they see the warning.
- Enable rules for API and bulk imports. Under the duplicate rule settings, check the boxes for when records are created via API. Most orgs leave this off by default, which means each integration and data import bypasses duplicate checking entirely.
- Create Duplicate Record Sets. Even when you allow duplicates through, configure the rule to create a Duplicate Record Set. This gives you a queue to review later.
How Do You Report on Duplicates in Salesforce?
Duplicate Record Sets are the answer, and most admins never look at them. Every time a duplicate rule fires with the "Report" option enabled, Salesforce creates a Duplicate Record Set containing the matched records. These accumulate in the background whether or not anyone reviews them.
To see them, create a custom report type on Duplicate Record Sets with Duplicate Record Items as the child object. That report shows you each potential duplicate pair your rules have flagged, when it was flagged, and which records are involved. Run it monthly. If the count grows faster than your team merges, your prevention rules need tightening.
Track total open duplicate sets as the backlog and newly created sets as the inflow. Compare those with approved merges over the same reporting window; a growing difference shows that review capacity is not keeping pace.
One limitation: Duplicate Record Sets only capture what your matching rules catch. Duplicates created before the rules were activated, or ones your fuzzy thresholds miss, rarely appear in the report. A periodic export-and-audit pass outside Salesforce catches what the rules can't see.
Merging Records: Object by Object
Finding duplicates is half the battle. Merging them without losing data is the other half.
Account to Account Merge
Account merges are the most complex because Accounts have the most related records: Contacts, Opportunities, Cases, Activities, Notes, Attachments, and custom child objects.
How to merge Accounts natively:
- Go to the Account you want to keep (the "master")
- Click "Merge Accounts" from the action menu
- Search for and select the duplicate(s), up to 3 total
- Choose which field values to keep from each record
- Click Merge
What happens to related records: Contacts, Opportunities, Cases, and Activities from the merged records move to the master Account. The duplicate Account records go to the Recycle Bin.
Watch out for: Account Team members, sharing rules, and custom lookup relationships. These don't generally merge cleanly. Check your master Account after merging to make sure nothing was lost.
Contact to Contact Merge
Contact merges are simpler but still need care.
- Navigate to the Account that contains the duplicate Contacts
- Select "Merge Contacts" from the related list or use the Duplicate Record Set
- Choose the master record
- Select field values from each record
- Merge
Activities from merged Contacts transfer to the master. Campaign Member records are preserved. If both Contacts were in the same Campaign, the earliest membership date is kept.
Lead to Lead Merge
Lead merges work the same way as Contact merges. Go to the Leads tab, find the duplicates, choose a master, select field values, merge.
One thing to watch: Lead conversion history. If one Lead was previously converted and then re-created (it happens), merging the duplicate into it may produce unexpected results. Generally check the Lead History after merging.
Before merging: Export the candidate records and their stable identifiers. Keep that review file outside the merge workflow so the team can compare approved values and related records after the operation.
Handling Duplicates at Scale
Salesforce's native merge can support a limited review queue. Measure the candidate volume, ambiguity, and reviewer capacity before deciding whether manual review or a batch workflow fits the project.
Third-party tools
| Tool | Strengths | Pricing |
|---|---|---|
| Validity DemandTools | Mature, powerful merge rules, bulk operations, good for large orgs | Subscription, contact vendor |
| Cloudingo | AppExchange native, good UI, automated scheduling | Starting ~$1,000/year |
| DataGroomr | AI-powered matching, good for complex duplicates | Starting ~$99/month |
| Duplicate Check | Real-time and batch, cross-object matching | Free tier available |
These tools commonly identify duplicate sets with configurable matching logic, preview merges before execution, and process approved merges in bulk. Compare the user interface, matching controls, review workflow, and current quote on the same sample.
Bulk merge process
- Export your duplicate sets. Use your tool to identify potential matches and export them to a spreadsheet for review.
- Review a sample. Check the first 100 pairs manually to make sure the matching logic is right. False positives are expensive to undo.
- Define merge rules. Which record survives? Usually the one with the most recent activity, or the one with more complete data. Define this as a rule rather than a case-by-case decision.
- Run a test batch. Check that related records transferred, field values are correct, and nothing disappeared.
- Process the rest. Once you're confident in the rules, run the full batch.
- Verify. Review a representative sample of merged records, including ambiguous and rejected candidates.
Common Duplicate Management Mistakes
Using an alert where a block is intended. Test how users respond to alerts in the actual workflow. Reserve blocking for reviewed high-confidence rules, and route lower-confidence candidates to an alert or review queue.
Not enabling rules for API and imports. This is the single most common oversight. Your web forms, integrations, and CSV imports are probably your biggest source of duplicates, and they bypass UI-based duplicate rules by default. Enable API enforcement.
Merging without a master record strategy. If your team doesn't know which record to keep as the master, they'll make inconsistent choices. Some keep the older record, some keep the newer one, some pick randomly. Define a policy: master record is the one with the most recent Activity, or the one owned by the Account Owner, or the one with the most complete data. Pick one and stick with it.
Ignoring cross-object duplicates. A person can exist as both a Lead and a Contact in Salesforce simultaneously. These are technically on different objects, but they're still duplicates. Use cross-object matching rules to catch Lead-to-Contact matches.
Treating deduplication as a one-time project. Measure new duplicate candidates after the cleanup by source and intake path. Use that evidence to adjust matching and prevention rules; otherwise the same sources can recreate the problem.
When to DIY vs. Outsource
If you have fewer than 500 duplicate pairs, you can handle this with Salesforce's native tools in a few days. Standard matching rules, a duplicate rule set to Block, and manual merging.
Between 500 and 5,000 duplicates, a third-party tool pays for itself. The time savings from bulk merging alone justifies the spend.
Above 5,000 duplicates, or if your matching logic needs to be complex (handling subsidiaries, international entities, multiple name variations), it's worth bringing in help. We do this kind of cleanup regularly. The hard part is building matching logic that catches real duplicates without creating false positives that merge records that should have stayed separate.
Common Questions About Salesforce Duplicate Management
What's the difference between matching rules and duplicate rules in Salesforce?
In Salesforce duplicate management, matching rules define candidate comparisons and duplicate rules define the resulting action. Document the paired rule names, scope, and expected behavior, then test create and edit paths before activation.
Can I merge Salesforce records in bulk?
Check the platform's current duplicate-management documentation for native limits and supported workflows. For bulk work, compare candidate tools on rule controls, preview, rollback, exception handling, and performance on the same sample.
Will merging Salesforce records lose data?
Before merging, define the master record, field-survival rules, and related-record checks. Verify the current Salesforce recycle-bin behavior, export a backup, and test restoration rather than assuming a merge can be reversed.
How do I prevent duplicates from entering Salesforce in the first place?
Configure duplicate rules with the "Block" action for high-confidence matches (same email). Enable the rules for API and import channels rather than the UI. For Leads, enable cross-object matching to catch Lead-to-Contact duplicates. No system is perfect, but this setup catches the majority of incoming duplicates.
Do duplicate rules check records that already exist in Salesforce?
No. Duplicate rules only evaluate records at the moment they're created or edited. Existing duplicates sitting untouched in your org are invisible to them. To find those, run a duplicate job from Setup (available with standard matching rules), use a third-party tool, or export and match the data outside the CRM.
How many duplicate rules can a Salesforce org have?
Check the current platform documentation before designing the rule set, then reserve capacity for the objects and match logic the team expects to maintain.
Thousands of duplicates in your Salesforce? We can identify, review, and merge them without losing a single Activity or Opportunity. We do this each week.
Get a Free Duplicate AssessmentRelated: All Salesforce Guides | Duplicate Contacts Guide | Company Name Normalization | Data Quality Audit
About the Author
Rome Thorndike is the founder of Verum. The career stop he keeps coming back to is Microsoft, where he built ML models for enterprise customers and learned how brittle operational data gets once you look closely at it.