Salesforce Duplicate Rules That Catch Dupes, Not Valid Records

Salesforce duplicate rules flag or block duplicate records the moment they're saved. Each one pairs with a matching rule that sets which fields to compare and whether the match is exact or fuzzy. Configure them per object: exact email matching with a Block action for Contacts, fuzzy name matching with a warning for Accounts. That balance catches real duplicates without stopping valid records.

When was the last time you checked whether your Salesforce duplicate rules actually work? Most admins activate a rule once, see no error, and assume the job is done. Then the duplicate tickets keep coming, your next campaign emails the same contact twice, or a rep gets blocked from saving a record that was never a duplicate.

Here is the part most guides skip: duplicate rules rarely fail because the feature is broken. They fail because of how the matching rule and the actions are configured. A rule set to warn when you need it to block. A matching rule that was never activated.

This guide fixes the setup and the judgment behind it. By the end, you can configure rules per object, choose Block or Allow on purpose, and know why a rule skips a record entirely.

Duplicate Rules vs Matching Rules: The Quick Mental Model

A matching rule decides how Salesforce compares two records, field by field. A duplicate rule decides what Salesforce does when a match is found, and on which object. You need both: the matching rule finds the duplicate, and the duplicate rule acts on it.

The match method sets your hit rate. Exact match flags a Contact only when the field is identical, so two records with sam@acme.com collide, but Sam and Samuel never do. Fuzzy match catches close variants, so "Acme Inc" and "Acme Incorporated" read as one company. Use exact on Email and record IDs. Use fuzzy on company and personal names, where spelling drifts.

Confidence is set per field, not by one global slider. So a Contact rule can demand an exact Email match while staying loose on First Name. That is how you catch the same inbox entered twice without merging two real people who share a name.

Get the Email field matching right, and a contact never enters yourSalesforce email campaigns under two records, so your send volume tracks your real audience instead of an inflated one.

How to Set Up and Activate Duplicate Rules

Salesforce duplicate rules setup runs in a fixed order: build the matching rule, create the duplicate rule and map it, set the action, then activate. Each step depends on the one before it, and skipping the order is the most common reason setup silently fails.

Step 1: Create a Matching Rule

Build the matching rule first, because the duplicate rule has nothing to point to until it exists. In Setup, type Matching Rules in Quick Find, click New Rule, and pick the object. Add the fields to compare and set a method for each.

For a Contact rule that protects your email list, set Email to Exact so two records with the same address collide. Add a fuzzy name field only if you want near-matches flagged too. The fields you pick here decide whether your Salesforce matching rules setup runs precisely or noisily later.

One dependency people miss: exact Email matching only catches dupes when the addresses are clean, so a single typo splits one subscriber into two records.Verify your email data before you rely on it.

Then activate the matching rule. Activation triggers a background scan that indexes every record on the object, which can run long on large orgs. Salesforce emails you when it finishes.

Step 2: Create the Duplicate Rule and Map It

Create the duplicate rule and connect it to the matching rule. In Setup, open Duplicate Rules, click New Rule, and choose the same object as your matching rule. In the Matching Rules section, select the rule you just activated, then confirm that Field Mapping shows as mapped.

Set Record-Level Security next. Record-Level Security sets whose records the rule can see during a match check. Enforce sharing rules that limit matching to records the user can already access. Bypass matches against every record in the org, so reserve it for cases that need org-wide detection.

Watch for the silent failure here: a duplicate rule with no mapped matching rule, or one pointing to a matching rule still marked inactive, does nothing on save and throws no error. The rule looks live but never fires, and the duplicate contacts keep entering your lists.

Step 3: Set Actions and Activate

Set the action, then turn the rule on. Choose an Action On Create and an Action On Edit. Block stops the save, Allow lets it through, and both can show an alert and log the match to a report.

Write alert text that tells the rep what to do, like: "This contact already exists. Open the existing record before creating a new one." Then click Activate. To activate duplicate rules in Salesforce, you toggle the duplicate rule itself, not just the matching rule it points to, which trips up admins who assume activating the matching rule was enough.

Leave report logging on either way, so every match lands somewhere you can review.

Standard vs Custom Rules: Clone Before You Build

Clone a standard rule before you build one from scratch. Salesforce ships three standard duplicate rules, one each for Accounts, Contacts, and Leads, already wired to standard matching rules.

They default to Allow and Report, so they warn but never block. That is why many orgs believe dedupe is on while the rules just watch the duplicates pile up. To get real prevention, clone a standard rule, change its action, and save.

The limit: you cannot edit standard matching rules, only the duplicate rule behavior. To change which fields get compared, build a custom matching rule. Salesforce'sduplicate rules documentation lists the current standard-rule fields.

Duplicate Rules for Accounts, Contacts, and Leads

Each object needs its own matching field and its own default action, because a duplicate on an Account is not the same problem as a duplicate on a Contact or Lead. Use this as your per-object starting point.

Accounts

Salesforce duplicate rules for accounts work best as two rules: an exact Account Name rule set to Block, and a fuzzy Account Name rule set to Allow with an alert. The exact rule stops obvious copies. The fuzzy rule catches the near-matches that the exact rule misses.

Fuzzy is deliberate here because real businesses use name variants. Inc versus Incorporated, acronyms, and regional branches like Tech Co North America versus Tech Co UK all read as different under exact matching. Add Billing Street or Website to the fuzzy rule so two separate companies with similar names do not collapse into one.

Keep fuzzy on Allow, never Block. A fuzzy Block stops reps from saving legitimate sister entities, and Account dupes are the costliest kind anyway: each duplicate Account forks the contacts, opportunities, and activities hanging beneath it.

Contacts

Base your Salesforce duplicate rules for contacts on an exact Email match, not name. Two different people often share a first and last name, but a shared business email almost always means the same person.

Map an exact Contact Email matching rule to a Block rule on create and edit, and skip fuzzy name matching on Contacts, which throws false positives that train reps to dismiss the alert.

One exception breaks email-exact logic: shared inboxes like info@ or sales@. Several real contacts can sit behind one address, so exclude generic mailboxes with filter logic, or pair Email with a second field.

Duplicates also cost you at send time. A contact stored twice counts as two recipients, which pads your send count and distorts open rates.MassMailer, a Salesforce-native email tool, sends straight from live Lead and Contact records, so a deduped base means each person is emailed once, and your open rates reflect real people.

Leads and Lead-to-Contact Matching

Salesforce duplicate rules for leads need four rules, not one: Lead-to-Lead, Lead-to-Contact, Contact-to-Contact, and Contact-to-Lead, all on exact Email. The cross-object pair is the part most orgs miss. Without a Lead-to-Contact rule, someone you already converted to a Contact comes back through a form and lands as a fresh Lead, splitting their history across two records.

Use the cross-object option inside the duplicate rule, Compare leads with contacts and Compare contacts with leads, and build the mirrored pair so detection works whichever record is created second.

Set the action per rule. On Lead-to-Contact, default to Allow plus alert. A hard Block turns away legitimate inbound: an existing customer filling a new form, or a second buyer at the same account. Reserve Block for the same-object pairs, Lead-to-Lead and Contact-to-Contact, where a match is far more certain.

When Should a Salesforce Duplicate Rule Block or Allow?

Block the matches you are sure about, and allow with an alert on the ones you are guessing at. That one call decides whether your rules protect data or annoy your reps.

• Block on high-certainty matches: exact Email, exact Account Name, exact record ID.
• Allow plus alert on fuzzy or partial matches: company-name variants, similar person names, anything where a false positive is plausible.

False positives come from overbroad criteria. A rule that matches on Last Name alone blocks two unrelated people who share a surname, so the wider the criteria, the more valid saves it rejects.

Do not roll out a Block rule org-wide on day one. Start it on Report-only, watch the duplicate report for a week, then switch to Block once you can see what it would have caught. A day-one Block buries your support queue in blocked-save tickets for records that were never duplicates.

One team switched on a fuzzy Account Block rule, and reps could no longer save valid regional subsidiaries, because the names were close enough to trip the match. Adding Billing Street to the criteria and dropping the rule to Allow plus alert fixed it. The duplicates still got flagged, and the real saves went through.

Aim for a rule your reps trust. A rule that fires too many false alarms gets ignored, and an ignored alert protects nothing, not your reports and not the list behind your nextemail campaign.

Salesforce Duplicate Rule Limitations and Exceptions

Active duplicate rules still let duplicates through, because several Salesforce entry pointsskip the rules. Knowing where they skip tells you where dupes slip into your records and your campaign lists despite a clean setup.

You can run up to five active duplicate rules per object, and they fire in the order you set. Put your strictest rule first, because once a rule finds a match, every rule after it skips that record.

Duplicate rules do not run in these cases:

• Quick create and Community self-registration
• Lead conversion, unless Use Apex Lead Convert is enabled
• Records restored with Undelete
• Manual record merge
• Records synced through Einstein Activity Capture

Bulk loads skip the rules, too. Records added through Data Import Wizard, Data Loader, or the API bypass the UI duplicate check, so one import can reintroduce every duplicate your rules block on save, and those duplicates flow straight into your next campaign send.

Web-to-Lead behaves the opposite way. A rule set to Block, or even Allow with an alert, blocks any matchingWeb-to-Lead submission outright. The prospect sees a duplicate error, and the lead never lands, so you can lose real inbound. To keep legitimate submissions, add a condition that exempts your default Web-to-Lead user from the rule.

So active rules are one layer, not full coverage. Imports and the API let duplicates in, and Web-to-Lead can lock real leads out, so each path needs its own fix outside the rule itself.

How to Clean Up Duplicates Already in Salesforce

Duplicate rules only fire on create and edit, so they never touch the duplicates already in your org. Clearing them is a separate job, and the right tool depends on your edition and volume.

Size the problem first with a report on the Duplicate Record Sets and Duplicate Record Items objects, or by adding Show Unique Count to an existing one.

For one-off fixes, open a record and use the Potential Duplicates related list. It combines up to three records into one, and you pick the master and the surviving field values. The merge is irreversible, so check before you confirm.

For scale, run a Duplicate Job. It scans the whole database against your matching rule and merges in batches, but only on Performance and Unlimited editions.

Rules prevent new duplicates. A cleanup pass clears the ones already doubling up in your campaign lists and reports.

Make Your Salesforce Duplicate Rules Work

Salesforce duplicate rules work when your matching criteria and actions match how your org defines a duplicate. Build the matching rule first, map and activate the duplicate rule, choose Block or Allow per object, then watch the report to see what they catch.

Mind the gaps too: imports, the API, and Web-to-Lead need fixes outside the rules, and existing duplicates need their own cleanup. Get this right, and you see fewer duplicates in your reports, accurate send counts, and no merge tickets.

Clean lists send better, so dedupe your contacts, then run your next campaign straight from those live Salesforce records with MassMailer.