The Two Halves
Salesforce’s duplicate management is two coupled features:
- Matching Rules define what counts as a duplicate — field-level matching criteria.
- Duplicate Rules define what to do when a duplicate is found — block, allow with warning, or allow silently.
You can create Matching Rules without Duplicate Rules; the opposite isn’t useful. Configure the matching first, then the actions.
Default Rules
Salesforce ships with default Duplicate Rules and Matching Rules for Lead, Contact, and Account. They’re a starting point, not a production-ready configuration.
The defaults typically:
- Match on email (exact) plus fuzzy first/last name.
- Block the duplicate with a warning.
Activate them in Setup → Duplicate Rules → Activate. Then customize.
Writing a Matching Rule
Navigate to Setup → Matching Rules → New Rule. For each field:
- Field selection — which field to compare.
- Match method — exact or fuzzy.
- Match blank fields — whether two blank values count as a match.
Example: a Contact matching rule on Email (Exact) AND Last Name (Fuzzy).
The rule activates after a brief index-build delay. You’ll see rows count up as Salesforce processes the existing data.
Fuzzy Matching Details
Salesforce’s fuzzy matching handles:
- First names: “Jim” matches “James,” “Bob” matches “Robert.” Uses a built-in nickname list.
- Last names: “Smyth” matches “Smith,” phonetic matching.
- Addresses: “St.” matches “Street,” suite handling.
- Phone: different formats match (dashes vs. parens vs. spaces).
For emails, fuzzy isn’t available — emails are treated as exact, though case-insensitive.
For entirely custom matching logic, you’d supplement with flow-based or Apex checks; out-of-the-box fuzzy covers common name/address variation.
Writing a Duplicate Rule
A Duplicate Rule:
- Object (Lead, Contact, Account, custom).
- Matching Rule to use.
- Action on create (Block, Allow with Alert, Allow).
- Action on edit (same options).
- Entry criteria — optional, to limit which records evaluate.
Common shape: “On create, block duplicates. On edit, allow with alert.”
Block prevents the save entirely. Allow with Alert lets the user override but shows a warning. Allow silently records the duplicate in Duplicate Record Sets without user notification.
Allowing With Alert: The Practical Default
Hard blocks frustrate users when the “duplicate” is genuinely different. A person named “John Smith” who works at both Acme and Beta might legitimately have two records.
Allow With Alert shows the user the potential duplicates and lets them override. The user reviews; if they decide it’s a dupe, they work with the existing record. If not, they proceed.
Blocks are appropriate when:
- The object has strict uniqueness requirements (tax IDs, account numbers).
- Downstream integrations cannot tolerate duplicates.
- Business policy mandates single-record-per-customer.
Default to Allow With Alert unless there’s a reason to block.
Duplicate Record Sets
Salesforce automatically maintains Duplicate Record Sets — groups of records flagged as potential duplicates of each other. Users with the right permission can view, compare, and merge them.
Access via:
- Standard list view Duplicate Record Sets.
- Related list on a record (showing other records in its set).
- Report type Duplicate Record Set.
Review duplicate sets periodically. Unaddressed duplicate sets accumulate and mask real operational issues.
Merging Duplicates
Three merge paths:
- UI merge: users merge 2–3 records from the record detail page. Manual, familiar.
- Apex merge: programmatic merging (e.g., as part of a cleanup Flow).
Database.merge(master, duplicates). - Mass merge tools: AppExchange packages or Salesforce’s Lightning Data tools.
Merging retains one master and deletes the others, rolling related records onto the master. Complex objects with custom master-detail relationships merge with caveats — test in sandbox before mass operations.
Bulk Loading Considerations
Duplicate Rules fire on every create or update, including bulk loads from Data Loader or API.
Implications:
- A bulk load of legitimate new records that happen to trigger a duplicate rule can block 100% of inserts.
- Turning off the rule, loading, turning it back on is a common workaround — but leaves a window where duplicates slip in.
Preferred pattern:
- Configure the rule to “Allow with Alert” for the bulk context, via entry criteria on the user profile (skip rule for Integration user).
- Clean up duplicates post-load via a review flow.
Cross-Object Duplicates
Standard Matching Rules compare within one object. To check “does this Lead match an existing Contact?” you need a separate Matching Rule that targets Contact but is invoked during Lead operations.
The “Include match against Contact in Lead duplicate rule” option enables this cross-object check — useful for Lead conversion flows where you want to flag a Lead that duplicates a Contact.
Performance
Matching rules are backed by match indexes Salesforce builds and maintains. Adding fuzzy fields or many fields to a rule increases index cost but typically remains performant.
Very large orgs (tens of millions of Accounts) may notice save latency with complex rules. Monitor save times post-deploy.
Tuning for False Positives
You’ll get false positives. Tactics:
- Narrow matching. Adding a more specific field (phone, account) reduces overlap with common-name matches.
- Adjust fuzzy strictness. Exact-match on one field plus fuzzy on others is usually better than fuzzy everywhere.
- Entry criteria. Limit the rule to records that matter (exclude test records, inactive users).
Tuning is ongoing. A rule that’s right today will need adjustment in six months as data patterns shift.
Anti-Patterns
Blocking by default. Users learn to hate the rule and push back.
Duplicate rules on every custom object. Most custom objects don’t need duplicate management. Apply where it matters.
Ignoring duplicate record sets. Accumulating thousands of unreviewed sets signals broken process, not handled duplicates.
Manual merge at scale. If you have 10,000 duplicates, manual merging isn’t the answer. Script it or use a tool.
Frequently Asked Questions
Does Duplicate Management work on external objects?
No — Matching Rules apply to native and custom Salesforce objects.
Can rules work across record types?
Yes — rules apply across record types unless entry criteria scope them.
Is there an API for duplicate checking?
Yes — the /sobjects/{object}/findDuplicates/{id} endpoint and the Datacloud.FindDuplicates.findDuplicates() Apex method let you check without committing a save.
How do duplicate rules interact with Salesforce Data Cloud identity resolution?
They’re separate systems. Duplicate management is for operational CRM records. Identity resolution in Data Cloud is for the unified profile layer. Use both.