# Salesforce duplicate rules and matching rules: what they block, what they only warn about, and what a sales manager should check

https://salesbond.app/blog/salesforce-duplicate-rules-matching-rules-manager-check/
Published: 2026-10-18 · Updated: 2026-10-26

Salesforce duplicate rules decide what happens when a new record looks like an existing one: the save is blocked, or it goes through with a warning. Matching rules decide what “looks like” means, field by field.

A sales manager does not need to build either. What a manager needs is to choose block-or-warn for each object (Lead, Contact, Account), know that imports and lead conversion are where duplicates get past the warning, and agree who merges the duplicates the rules let through. That is the job this article is about.

## Why duplicates reach the manager first

The admin sees a duplicate as a data quality metric. The rep sees it as somebody else’s record. The manager sees it on Thursday, when two reps have the same company in two accounts, both have an open opportunity on it, and the customer has had two pricing conversations in one week.

Nobody did anything wrong in the CRM sense. Orgs created since Spring ’15 get standard duplicate rules for accounts, contacts and leads, and in Salesforce’s own walkthrough the standard rule simply alerts the rep, who can then go to the existing record or carry on and save the new one ( [Trailhead: Duplicate Management](https://trailhead.salesforce.com/content/learn/modules/sales_admin_duplicate_management/sales_admin_duplicate_management_unit_1)). An alert is a yellow box a rep reads once and never again. The second account exists because the alert allowed it to exist.

So the first thing to accept is that duplicate rules are a policy, and policies are the manager’s. The admin can set the behaviour you ask for. The problem in most teams is that nobody asked. On HubSpot the same policy question applies, and here is a [weekly duplicates check in HubSpot](https://salesbond.app/blog/hubspot-data-quality-command-center-duplicates/).

## Matching rules vs duplicate rules, in one paragraph

A matching rule says which fields make two records “the same”: for example, same email, or a fuzzy match on company name plus the same city. A duplicate rule says what Salesforce does when a matching rule fires: block the save, or allow it with an alert, and whether to log the pair for a report. One duplicate rule can use up to three matching rules, and an object can carry up to five active duplicate rules ( [Plauti: Managing duplicate records with Salesforce’s native tools](https://www.plauti.com/guides/tracking-duplicates-with-salesforce)). Salesforce ships three standard matching rules, one each for business accounts, contacts and leads, and the contact and lead ones mix exact matching with fuzzy methods on names ( [Trailhead: Prevent duplicate data](https://trailhead.salesforce.com/content/learn/modules/sales_admin_duplicate_management/sales_admin_duplicate_management_unit_2)). That is all the vocabulary you need. When your admin says “the matching rule is too loose”, they mean reps see alerts on records that are not duplicates. When they say “the duplicate rule is on Allow”, they mean the alert is advisory.

![Diagram: a matching rule decides if records are the same, then a duplicate rule either blocks the save or allows it with an alert](https://salesbond.app/wp-content/uploads/2026/10/salesforce-duplicate-rules-matching-rules-manager-check-2.png)

## Block or warn: a decision for each object

Our position: Block on Account, Allow with alert and report on Contact, Allow with report only on Lead. Here is the reasoning, so you can disagree with the reasoning rather than the setting.

Most advice you will read, including what AI assistants give when you ask, says the opposite for accounts: start with a warning and never block on a fuzzy account match. That advice is right about the fuzzy part. So our Block comes with two conditions. First, it applies when a record is created; on edit, set the rule to Allow and Report, so a rep fixing an address is never locked out of a record they already own (create and edit are separate settings on a duplicate rule, as the Trailhead unit shows). Second, the matching rule behind it is strict: exact account name plus the same billing city or website, not the standard fuzzy one. The real risk is the account hierarchy. A subsidiary or a sister company can share a name and a city with its parent, and a strict rule will still stop the rep who is creating it legitimately. When that happens the admin creates the record, and you have spent five minutes instead of a quarter of double pipeline.

Why block at all? Accounts are where duplicates cost money. Two account records mean two owners, two pipelines and two reps who both think the customer is theirs. Almost nobody has a reason to create a second account with the same exact name and the same billing city on the spot. Blocking costs a rep two minutes once a month. Not blocking costs you a Thursday.

Contacts are different. The same person can genuinely exist twice in a messy world: an old email at a previous employer, a partner contact who also buys. Block here and reps start spelling names wrong to get past the rule, which is worse than a duplicate. Allow, show the alert and tick Report so the pair is logged where you can read it later.

Leads are the hardest call. Lead volume is high, data is thin, and a blocked lead is a lead nobody follows up. The standard Lead matching rule is fuzzy on names, so a strict block would refuse real prospects. Let them in, don’t bother the rep with an alert they will ignore anyway and review the report weekly. One thing to ask the admin for: a matching rule can compare across objects, lead against contact, not only lead against lead (the Plauti guide above walks through it). That is the duplicate that hurts most on the sales floor. A “new” lead from someone who is already a contact on a customer account means one rep cold-calls a person another rep talks to every week. If your team runs a queue for new leads, read [how to audit who actually owns the new leads](https://salesbond.app/blog/salesforce-lead-assignment-rules-audit/) first, because a duplicate lead sitting in a queue is two problems at once.

If the matching rules are new don’t switch Block on the same day. Run everything on Allow with Report for a couple of weeks, read what lands in the report, and only then turn Block on for accounts. You’ll see how often the strict rule would have fired, and on which records.

Write the three choices down and give them to the admin as a request, with the object, the action and the reason. “Account: Block on create, strict match, because two accounts mean two owners.” It takes the admin less than an afternoon and it takes you the whole afternoon to decide, which is the right split.

## Imports and lead conversion: where duplicates slip through

Now the part the admin guides skip. Duplicate rules are built for a rep typing into a form. Most of your duplicates do not arrive that way.

Lead conversion is the first gap. When a rep converts a lead, Salesforce creates or links an account and a contact, and conversion is not the same path as saving a form. Community guides list it among the cases where duplicate rules don’t run ( [Apex Hours: Duplicate rules and matching rules](https://www.apexhours.com/duplicate-rules-and-matching-rules-in-salesforce-2/)), while Salesforce’s developer docs describe a way for conversion code to run them. So whether your rules see the twin at that step depends on how your org converts leads, and that is a question for the admin, not an assumption. What is the same everywhere is the rep: the convert screen can offer an existing account to attach to, and a rep in a hurry creates a new one. If you care about account duplicates, the convert step is where to look.

Imports are the second gap. The Data Import Wizard asks the person importing how to match incoming rows to existing records, on the import screen itself, which is a separate choice from your duplicate rules ( [Trailhead: Import data](https://trailhead.salesforce.com/content/learn/modules/lex_implementation_data_management/lex_implementation_data_import)). Loads through the import tools and the API, [Data Loader](https://salesbond.app/blog/salesforce-data-loader-vs-workbench-bulk-update/) included, are on the list of cases where duplicate rule settings behave differently from a rep saving a form (Apex Hours, same page). The practical consequence needs no documentation: there is no screen to show an alert on. A 3,000-row trade show list loaded by marketing on a Friday can carry every duplicate it contains past your Allow-with-alert rule on Contact, and nobody will have seen a yellow box. So treat the morning after a big import as the time to run the twenty-record check below on the imported records.

Three questions to ask before any import, and they are management questions, not technical ones. Who is importing, through which tool. Which duplicate rules apply to that object, and what the admin expects them to do during that load. Who looks at the result afterwards, and by when.

## A twenty-record check

You do not need a data quality project to know whether duplicates are a problem. You need twenty records and half an hour.

Open the Accounts tab, list view “All Accounts”, sort by Account Name. Scroll until you find a name that appears twice, or nearly twice (“Acme Ltd” and “ACME Limited”). Note it. Keep scrolling until you have twenty accounts you have looked at properly, counting the ones with a near twin. Do the same on Contacts sorted by Email, where duplicates are easiest to spot because an email is either identical or it is not.

Then open the duplicates report. If your rules have Report ticked, Salesforce has been logging the pairs it saw as duplicate record items, and your admin can build a report on them with a custom report type in a few minutes ( [Trailhead: Prevent duplicate data](https://trailhead.salesforce.com/content/learn/modules/sales_admin_duplicate_management/sales_admin_duplicate_management_unit_2)). The question is simply whether anyone has opened it since the rules went live. An empty report with twins in your list view means Report is not ticked, or the rules are off, or the twins came in through an import or a conversion the rules never saw. Each of those is a different conversation with the admin, which is why you check before you ask.

What you are looking for is a ratio, not a count. Two twins in twenty accounts is a hygiene item for the weekly review. Six in twenty is a reason to stop and fix the rules before you touch anything else, because every report you run on the pipeline is counting some customers twice. If your [weekly opportunity audit](https://salesbond.app/blog/salesforce-opportunity-audit-sales-manager/) already shows the same company name on two open deals with two owners, you have your answer without the list view.

For Pipedrive teams we wrote the same check against that CRM’s merge tools in [duplicate records in Pipedrive](https://salesbond.app/blog/duplicate-records-in-pipedrive/); the ratio logic is identical, the buttons are not.

## Who owns the merge

A duplicate rule finds the pair. A person has to merge it, and merging is where teams get stuck, because merging an account means one rep loses a record.

The rule we use: the owner of the older record owns the merge, and the merge happens within the week the pair was found. Older record, because it usually has the history: the activities, the closed opportunities, the notes. The newer one is usually teh one created in a hurry. Salesforce lets the person merging pick the master record and choose which field values survive, so nothing has to be lost, but somebody has to sit down and do it. And if one of the pair sits in a queue with no owner at all, the rule has nobody to point at; [the queue audit](https://salesbond.app/blog/salesforce-queues-unowned-records-audit/) is where to fix that first.

Give the merge a place in the the calendar rather than a line in a policy. Ten minutes at the end of the weekly pipeline review, duplicates report open, oldest first. If a pair is contested (two reps, two live conversations), the manager decides on the spot who keeps the account and the other rep is told that day. Letting a contested pair sit for a month is how you get the double pricing call.

A disclosure, since we are at the point where a manager wants the list without building it: we build SalesBond, a sales management layer on top of the CRM a team already uses. Checking the CRM for records that break the rules you agreed, including the ones that arrived through a side door, is the kind of thing it does, and the hard part was never the list. It was deciding Block or Allow per object, and picking who owns the merge. If you have done those two, [check your CRM with SalesBond](https://salesbond.app/) for the rest.

Your admin will probably push back on Block for accounts, because they hear the complaints when a rep can’t save. Take the complaint, and bring the two weeks of report data to that conversation. A rep who couldn’t save a second “Acme” is a rep who found the first one.