Salesforce duplicate rules

Duplicate records don't just break data quality - they break territory coverage, pipeline reporting, and customer-facing experiences. A rep works an account that another rep already closed. A marketing campaign sends three versions of the same email to one contact. A forecast double-counts revenue because the same opportunity lives under two account records.

Salesforce duplicate rules are the native mechanism to stop this. But only if they're configured correctly. Most Salesforce orgs have duplicate rules turned on but not optimized. The Report option is never enabled. Rule limits are hit and ignored. Import-time exposure through Data Loader and API integrations goes completely unaddressed.

This guide covers the matching rules vs. duplicate rules distinction, step-by-step configuration for both, Apex enforcement for bulk imports, Duplicate Jobs for retroactive cleanup, and reporting on duplicate detection activity. Plus where native Salesforce duplicate rules hit a wall.

1. Matching rules vs. duplicate rules: the distinction that matters

This is the most important concept in configuring Salesforce duplicate rules, and it trips up even experienced admins: matching rules and duplicate rules are two separate objects that do nothing without each other.

Matching rules identify. They define which fields to compare and which algorithm to apply, exact match, fuzzy match, or a combination. On their own, they're inert. A matching rule sitting in Setup without an associated duplicate rule will never fire.

Duplicate rules act. They define when to run (on record create, edit, or both), which object to watch, and what to do when a match is found. Two possible outcomes: alert the user and let them proceed, or block the save entirely.

The logic chain runs in sequence every time a user creates or edits a record:

1. User creates or edits a record in Salesforce.
2. The duplicate rule fires on that object.
3. The duplicate rule calls its associated matching rule(s).
4. The matching rule compares field values against existing records using the configured algorithm.
5. If a match is found, the duplicate rule enforces its action: alert or block.

Think of matching rules as the detection engine and duplicate rules as the enforcement layer. You need both, and they need to be wired together correctly.

2. Salesforce's standard duplicate rules: what you get out of the box

Salesforce ships three standard matching rules. One each for Accounts, Contacts, and Leads. These are pre-configured and active by default in most orgs.

2.1. Where standard rules fall short

Standard Salesforce duplicate rules cover the basics, but they leave real gaps:

• No custom object coverage. If your org uses custom objects for locations, franchises, or properties, standard rules ignore them entirely.
• Cross-object matching is limited. Lead-to-Contact matching exists but Lead-to-Account and Contact-to-Account cross-object matching is not natively supported beyond basic scenarios.
• Country code phone mismatches. A contact entered as "+1-555-123-4567" and another as "555-123-4567" may not flag as duplicates depending on the matching algorithm.
• Default error messages are unhelpful. End users see a generic "possible duplicate" warning without enough context to decide whether the match is real or a false positive.

3. How to create a custom matching rule in Salesforce

When the standard Salesforce matching rules don't cover your use case, custom objects, non-standard field comparisons, or tighter matching logic. You create a custom matching rule.

3.1. Step-by-step: creating a matching rule

1. Navigate to Setup → Matching Rules → New Rule.
2. Select the object (standard or custom, matching rules can be applied to custom objects, a capability many admins don't realize exists).
3. Name the rule with something descriptive. "Account Name + City Match" tells you more than "Custom Rule 1."
4. Add matching criteria: select the fields to compare, choose the match method for each field, and set the match confidence threshold.
5. Save and Activate. An inactive matching rule does nothing. It must be activated before any duplicate rule can reference it.

3.2. Choosing the right match method

Two fundamental approaches, each with trade-offs:

In practice, the best Salesforce matching rules combine both methods: exact match on email or phone (high-confidence fields) with fuzzy match on name and company (high-variation fields). This gives you broad recall without drowning users in false positive alerts.

Matching rules for custom objects, including franchise locations, properties, or service territories, follow the same creation workflow. If your org tracks these on custom objects, this is where native Salesforce duplicate rules can still add value.

4. How to create and configure duplicate rules in Salesforce

Once your matching rules are in place, duplicate rules define the enforcement. This is where you control what Salesforce actually does when a potential duplicate is detected.

4.1. Step-by-step: creating a duplicate rule

1. Navigate to Setup → Duplicate Rules → New Rule.
2. Select the object the rule applies to.
3. Name the rule and add a description. The description appears in the UI when the rule fires. Make it useful for the end user, not just the admin.
4. Set Record-Level Security: choose whether matching applies only to records the user can see, or all records. "Enforce sharing rules" is the safer default for orgs with complex record visibility.
5. Set When to Run: on record create, on record edit, or both.
6. Choose the Action: Alert or Block.
7. Select the matching rule(s) to associate with this duplicate rule.
8. Save and Activate.

4.2. Alert vs. block: choosing the right action

Alert warns the user that a potential duplicate exists and lets them proceed. This is the right choice when false positives are common, when reps need to create records quickly, or when you're still tuning your Salesforce matching rules and want to observe match quality before enforcing hard stops.

Block prevents the save entirely. The user cannot create the record unless they modify it enough to clear the match. This is the right choice for high-confidence matching rules (exact email match, for instance) where you're certain the duplicate is real.

A blocked save with a poor error message is a frustrating user experience. Customize the message to tell the rep exactly what was flagged and what to do about it. "A contact with this email already exists. Search for [name] before creating a new record" is far more useful than "Possible duplicate detected."

4.3. Enabling the report option. The step most admins miss

When you configure a Salesforce duplicate rule, there's a checkbox labeled "Report" in the action settings. When enabled, Salesforce logs detected duplicates to Duplicate Record Sets even when the action is set to Alert (not just Block).

This is how you get duplicate creation rate visibility over time. Without this option enabled, Alert-mode rules fire, the user sees the warning, and no data is captured. You have no way to measure how many duplicates are being created, who's creating them, or which objects are most affected.

Enable the Report option on every active duplicate rule. This is the single most impactful configuration step that most Salesforce admins skip. And it's the prerequisite for everything in the Reporting section below.

4.4. Active rule limits

Salesforce enforces hard limits on active duplicate rules:

• 5 active duplicate rules per object.
• 3 matching rules per duplicate rule.
• 1 active matching rule per object within a given duplicate rule.

These limits matter when you're configuring Salesforce duplicate rules across multiple objects with different matching logic. Plan your rule architecture before building, hitting the 5-rule ceiling on a key object with no room for the rule you actually need is a problem you want to avoid.

5. Running a duplicate check in Salesforce: duplicate jobs

Salesforce duplicate rules catch duplicates at the point of create or edit. They don't retroactively find existing duplicates already sitting in your database. That's what Duplicate Jobs are for.

5.1. How to run a duplicate job

1. Navigate to Setup → Duplicate Jobs.
2. Select the object to scan.
3. Select the matching rule the job should use.
4. Run the job. Salesforce scans existing records against the matching rule and groups matches into Duplicate Record Sets.
5. Review the results in the Duplicate Record Sets tab.

5.2. Edition restriction

Salesforce Duplicate Jobs are only available in Performance and Unlimited editions. Enterprise edition orgs do not have access to this feature. There is also a 50-million record ceiling per job.

If your org is on Enterprise edition and needs retroactive deduplication, you'll need a third-party tool from the AppExchange, DemandTools, Dedupely, Plauti, or DupeCatcher are the most commonly used options.

5.3. Reviewing and merging duplicate record sets

A Duplicate Record Set is a group of records that the job flagged as potential matches. Each set contains two or more records with a confidence score from the matching rule.

The merge workflow for Contacts, Leads, and Accounts follows Salesforce's standard merge process: select the master record, choose which field values to keep from each duplicate, and merge. Child records (activities, opportunities, cases) are typically reparented to the master record.

What gets lost on merge: custom lookup relationships that aren't automatically reparented, manually created sharing rules on the deleted record, and any field values you chose not to keep. Review carefully before merging, especially on Account records with complex child hierarchies.

6. Duplicate rules in apex: programmatic enforcement

Salesforce duplicate rules fire when a user creates or edits a record through the UI. They do not fire by default on records inserted through Data Loader, API integrations, or bulk imports, which is exactly where many duplicate records originate.

For technically literate admins, Apex provides programmatic enforcement using Database.DMLOptions with the DuplicateRuleHeader and Database.DuplicateResult classes. This allows you to invoke duplicate rules during bulk data loads and API integrations that would otherwise bypass UI-level enforcement.

The Datacloud.FindDuplicatesResult API enables duplicate detection without attempting to insert the record - useful for pre-screening imports against existing records before committing any data.

When to use Apex enforcement:

• Bulk data loads via Data Loader or third-party ETL tools.
• API integrations that create records programmatically (enrichment tools, marketing automation, web-to-lead custom implementations).
• Scheduled batch processes that import records from external systems.

This is a conceptual overview, not a full implementation tutorial. Salesforce's Apex Developer Guide covers the full DuplicateResult class reference and implementation patterns.

If your org runs regular data imports that bypass the UI, Apex enforcement is not optional. It's the only way to close the import-time bypass gap in Salesforce duplicate rules.

7. Salesforce duplicate management reporting

Most Salesforce orgs never look at duplicate detection data because they never enable the Report option (Section 4.3 above). Once it's enabled, you can build reports on two standard objects: Duplicate Record Sets and Duplicate Record Items.

7.1. Building reports in Salesforce report builder

In Report Builder, select the Duplicate Record Sets report type. This gives you access to:

• Duplicate Record Set Name, the matching rule that created the set.
• Duplicate Record Items, the individual records flagged within each set.
• Created Date, when the duplicate was detected.
• Created By, the user who triggered the match (if applicable).

7.2. What these reports answer

With the Report option enabled and reports in place, admins can answer questions that most orgs have no visibility into:

• How many duplicates are we creating per week, and is the trend improving or worsening?
• Which reps or data sources are creating the most duplicates?
• Which object has the highest duplicate rate, Leads, Contacts, or Accounts?
• Are our matching rules catching real duplicates, or are they generating excessive false positives?

This is operational intelligence that turns Salesforce duplicate management from a reactive cleanup exercise into a measurable, improvable process.

8. Where native Salesforce duplicate rules hit a wall

Salesforce's native duplicate rules are a solid starting point, but they have a hard ceiling. Knowing where that ceiling is prevents you from over-investing in native configuration when a different approach is needed.

Third-party tools like DemandTools, Plauti, or Dedupely extend beyond these limits with bulk merge UIs, cross-object matching, and advanced fuzzy logic. For orgs where Salesforce duplicate management is a significant operational burden, evaluate these tools against the specific limitations you're hitting.

8.1. The upstream data quality problem

There's a broader issue that no configuration of Salesforce duplicate rules can address: the quality of data entering your CRM in the first place.

Duplicate rules catch duplicates at the point of UI entry. They compare what a user is entering against what already exists. They don't fix the source problem. When enrichment integrations or third-party data imports feed inaccurate or inconsistent records into Salesforce, misspelled business names, outdated addresses, phone numbers in non-standard formats. Those records are hard to match because they have no stable identifier to match against.

This is especially acute for local and SMB businesses, where the same business might appear as "Joe's Pizza," "Joe's Pizza LLC," "Joes Pizza Inc," and "Joe's Pizzeria" across different data sources. Standard Salesforce matching rules can catch some of these variations with fuzzy matching, but inconsistent source data creates a volume of near-duplicates that overwhelms rule-based detection.

DataLane addresses this upstream by building verified local business records from non-LinkedIn sources, state licensing data, permit filings, and local business registries. With entity resolution applied before the data reaches your CRM. When the source data is consistent, Salesforce duplicate rules work as intended. When it isn't, no amount of rule configuration compensates.

9. Configuration checklist: before you go live

Before activating Salesforce duplicate rules in production, confirm every item on this list:

• Matching rules activated, an inactive matching rule won't fire, even if a duplicate rule references it.
• Duplicate rules activated, confirm status in Setup; newly created rules are inactive by default.
• Report option enabled, on every active duplicate rule, not just Block-mode rules.
• Record-Level Security set intentionally, decide whether matching should cross sharing boundaries or respect them.
• Error messages customized, replace default messages with guidance that helps end users resolve the match.
• Duplicate Jobs scheduled, if your org is on Performance or Unlimited edition, run an initial retroactive scan and schedule recurring jobs.
• Reporting in place, build at least one report on Duplicate Record Sets to track duplicate creation rate over time.
• Apex enforcement configured, if your org runs Data Loader imports or API integrations, ensure duplicate rules fire on those paths.

Frequently asked questions

Frequently asked questions

The right call here turns on data coverage and workflow fit, not feature lists.