Your Pardot connector throws a “duplicate record” error on a contact that has never existed anywhere else in your org. Meanwhile, two obviously identical Accounts named “Acme Inc” and “ACME, Inc.” sit side by side in the same list view, and Salesforce never says a word. Both problems trace back to the same pair of features working exactly as configured — just configured wrong. If you’re trying to understand Salesforce duplicate rules vs. matching rules and why one keeps blocking a legitimate sync while the other lets real duplicates through, the confusion is common, and the fix is usually a short settings change once you know where to look. This is the same matching-criteria and exclusion work we do for clients during a Cloud Nexus org review, broken down here so you can run the audit yourself.
Quick Answer: A Matching Rule defines how Salesforce decides two records are the same. A Duplicate Rule defines what Salesforce does when it finds a match — block the save, allow it with a warning, or just report it. Integrations get blocked because most orgs run on the default Matching Rule, which keys on Name and Company or Account Name instead of email, and because most Duplicate Rules apply to every user by default, including connector and integration accounts. The fix has two parts: tighten the Matching Rule criteria to key on a more reliable field like email, and add a bypass for integration users on every Duplicate Rule touching a synced object. Our post on clearing a Pardot sync error queue shows exactly what it looks like when this goes wrong.
What’s the Difference Between a Duplicate Rule and a Matching Rule?
A Matching Rule and a Duplicate Rule do two different jobs, even though Salesforce groups them under the same Setup menu. The Matching Rule decides whether two records count as the same person or company, based on criteria you set per field. The Duplicate Rule takes that verdict and decides what Salesforce actually does about it — block the save, allow it through with a warning, or silently log it for a report.
Why Do Legitimate Integration Records Get Flagged as Duplicates?
Legitimate records get flagged because a Duplicate Rule applies to every user creating or editing a record unless it’s told otherwise, and an integration user is just another user as far as Salesforce is concerned. The Pardot connector, a middleware job, or an API integration all submit records the same way a rep typing into a form does. Consequently, a rule meant to stop reps from fat-fingering a second copy of the same lead ends up blocking automated syncs it was never designed to catch.
This is the same pattern behind cause four in our Pardot sync error queue breakdown — the connector hits a Duplicate Rule with no bypass, and the sync stalls instead of erroring loudly.
How Do You Exclude Integration Users From a Duplicate Rule?
You exclude integration users by adding them directly to the rule’s conditions rather than leaving it wide open to every user. Under Setup, open Duplicate Rules, select the rule, and edit its record-level security or conditions to bypass the connector’s specific user or a dedicated integration permission set. Salesforce also lets you set the rule’s action differently for different contexts, so an integration user can be set to “Allow” while a human user is still set to “Block.”
Keep a documented list of every integration user in the org — the Pardot connector user, any middleware service accounts, any scheduled API integration — so nobody has to guess which accounts need the exclusion the next time a rule changes. Our guide on Salesforce validation rule governance covers the same exclusion pattern for validation rules, and the two lists should be the same one.
How Should You Set Matching Rule Criteria to Avoid False Positives?
Matching criteria cause false positives when they key on fields that are common across unrelated records, and Name plus Company or Account Name is the most common offender. Two different people named “Mike Johnson,” or two unrelated companies that both go by “Summit Group,” will collide constantly under a name-based match. Email, by contrast, is close to unique per contact and rarely collides by accident.
Set the primary matching criteria to key on email wherever the object has a reliable one, and treat Name and Company matching as a secondary signal rather than the primary trigger. Fuzzy matching on name fields can still be useful as a supplement, but it should never be the only criterion driving a Block action on its own.
Should Duplicate and Matching Rules Be Part of Your Change Governance Process?
Duplicate and Matching Rules belong in the same change process as validation rules, because they fail for the exact same reason: someone changes a rule without checking who else depends on the object it touches. A marketing ops team adding a new lead source, a sales team requesting stricter matching after a bad data import, or an admin tightening rules ahead of an audit can all break a sync nobody on that team even knew existed.
This is exactly the kind of cross-system dependency we map out during a Cloud Nexus org review, checking your Duplicate Rules, Matching Rules, and validation rules together against every integration touching the org, rather than reviewing each one in isolation.
Frequently Asked Questions
Can a Duplicate Rule use more than one Matching Rule?
Yes. A single Duplicate Rule can reference multiple Matching Rules on the same object, and Salesforce evaluates all of them when checking for a match. This is useful when you want a strict email-based match to trigger a hard block while a looser name-based match only triggers a warning.
Why am I still seeing duplicates even though my Duplicate Rule is active?
An active Duplicate Rule only catches records that meet its Matching Rule’s criteria, so records that differ slightly in a matched field — a typo, a missing middle initial, a different abbreviation — can slip through even with the rule turned on. Existing duplicates created before the rule was active also won’t retroactively get caught; those need a separate merge pass.
Do Duplicate Rules replace validation rule governance?
No. Duplicate Rules and validation rules solve different problems and both need the same kind of change process around them. Our guide on Salesforce validation rule governance covers the broader process both rule types should share.
What do I do with duplicates that already exist in my org?
Fixing Duplicate and Matching Rules only stops new duplicates from being created. Existing duplicates need a separate merge pass, which our post on mass-merging duplicate Accounts and Contacts walks through directly.
How do I get help auditing our duplicate and matching rules?
A Cloud Nexus org review is a free 90-minute session where a senior consultant walks your Matching Rules, Duplicate Rules, and integration-user exclusions with you directly. You leave with a prioritized fix list showing exactly which rules are blocking real syncs and which are letting real duplicates through.
Are Legitimate Records Getting Blocked as Duplicates?
Our free 90-minute org review audits your Matching Rules, Duplicate Rules, and integration-user exclusions with a senior consultant. You leave with a prioritized fix list, not a 40-page PDF.
Book Your Free Org Review →
