Matching Rules and Duplicate Rules

Why Matching Rules and Duplicate Rules Matter

Duplicate data is one of the most expensive problems in any CRM. When the same account, contact, or lead exists multiple times, sales reps step on each other, marketing sends the same email twice, reports overcount pipeline, and users slowly stop trusting the system. Salesforce Duplicate Management is the native, declarative toolset that lets an administrator prevent duplicates at the moment of creation and edit, and also find and report on duplicates that already exist.

For the Advanced Administrator exam, this topic sits inside the Advanced Data and Analytics Management domain. You are expected to know not just that the feature exists, but how its two halves fit together, what each setting does, where the feature does and does not fire, and how to pick the right configuration for a described business scenario. Questions here are frequently scenario-based and test whether you can tell the difference between identifying a duplicate and acting on one.

The Core Concept: Two Rules Working Together

Salesforce Duplicate Management is built on two separate but linked components:

1. Matching Rule - defines how Salesforce decides that two records are a match. It answers the question: Is this record a duplicate of that record?
2. Duplicate Rule - defines what happens when a match is found. It answers the question: Now that we found a duplicate, do we block the user, warn the user, or just record it in a report?

A simple way to remember it: Matching Rules find; Duplicate Rules decide. A duplicate rule cannot work without at least one active matching rule, and a matching rule does nothing on its own until a duplicate rule references it.

Part 1: Matching Rules in Depth

What a Matching Rule Is
A matching rule is a set of field-level criteria plus a matching equation. When a record is saved, the matching rule compares the field values on the new or edited record against existing records of the specified object (or a related object) and returns the records it considers matches.

Standard Matching Rules
Salesforce ships with standard matching rules for Accounts, Contacts, Leads, and Person Accounts. These use sophisticated fuzzy logic that Salesforce maintains for you. They cannot be edited, but they can be activated or deactivated and referenced by any duplicate rule. For example, the Standard Contact Matching Rule looks at combinations of first name, last name, email, phone, mailing address, and account name using fuzzy matching so that Bob Smith and Robert Smith at the same email can be recognized as the same person.

Custom Matching Rules
You can build custom matching rules on standard objects and on custom objects. For each rule you define:

- Object: the object whose records are compared.
- Matching criteria: one or more fields, each with a matching method.
- Matching method: either Exact or Fuzzy.
- Match blank fields: a checkbox per field that decides whether two blank values count as a match. Leaving this unchecked is usually safer, otherwise every record with a blank phone could match every other blank phone.
- Matching equation: the AND/OR logic that combines the criteria, for example (1 AND 2) OR 3.

Exact vs. Fuzzy Matching
- Exact matching requires the strings to be identical (it is not case-sensitive for most text fields). It is available for virtually all supported field types.
- Fuzzy matching is only available for specific, predefined field types where Salesforce has built algorithms: First Name, Last Name, Company Name, Street, City, Title, Phone, Email (domain-aware), Zip, State, Country, and similar. Fuzzy methods handle nicknames, abbreviations, transpositions, acronyms, and common misspellings. You cannot apply fuzzy matching to an arbitrary custom text field such as Product Code__c; only Exact is available there.

Supported and Unsupported Field Types
Matching rules support text, email, phone, number, URL, picklist, date, checkbox, lookup (to certain objects), and address components. Notably, long text area, rich text area, multi-select picklist, formula, and encrypted fields are not supported as matching criteria. Picklists support Exact only.

Activation and Editing
A matching rule must be activated before it can be selected in a duplicate rule. Activation builds an index behind the scenes, which is why it may take several minutes. To edit a matching rule, you must first deactivate it. If that matching rule is used by an active duplicate rule, you must deactivate the duplicate rule first.

Key Limits to Memorize
- Up to 5 active matching rules per object.
- Up to 25 total active matching rules across the org.
- Up to 10 field criteria per matching rule.
- Up to 5 active duplicate rules per object.
- Each duplicate rule can reference up to 3 matching rules, each on a different object.

Part 2: Duplicate Rules in Depth

What a Duplicate Rule Is
A duplicate rule ties one or more matching rules to an object and specifies the behavior when a match is detected. Salesforce ships with standard duplicate rules for Accounts, Contacts, Leads, and Person Accounts; in newer orgs these are active by default, which is itself a popular exam fact.

Duplicate Rule Settings

1. Object - the object whose records trigger the rule when created or edited.

2. Record-Level Security - two options:
- Enforce sharing rules: the rule only compares against records the current user can see. A rep who cannot see another rep's leads will never be told about a duplicate among them.
- Bypass sharing rules: the rule compares against all records regardless of the user's access. The user is told a duplicate exists but still cannot open a record they lack access to. Choose this when the business says no duplicate anywhere in the org, even if the user cannot see it.

3. Action on Create and Action on Edit - set independently:
- Allow: the record saves. You can optionally add an Alert (a warning message with a list of possible duplicates that the user can review and then choose to save anyway) and/or a Report (records the match in Duplicate Record Sets for later analysis).
- Block: the record cannot be saved while a match exists. An alert message explains why. The Report option is not available with Block because nothing was saved.

4. Alert Text - the message shown to users. Customize it to tell users what to do, for example A contact with this email already exists. Please search before creating a new one.

5. Conditions - optional filters that restrict when the rule runs, based on record field values (for example only run on Leads where Lead Source equals Web) and/or user attributes such as Profile or Role (for example do not run for the Integration User profile). This is how you exempt an integration or a data steward team from blocking.

6. Matching Rules - select the matching rule(s) to use. Here you also configure cross-object matching: a duplicate rule on Lead can compare new leads against existing Contacts using a Contact matching rule, with field mapping between the two objects. This is the classic stop reps from creating a lead for someone who is already a contact requirement. Similarly, Account rules can compare against Person Accounts and vice versa.

Rule Order
When multiple duplicate rules exist on an object, you can reorder them. If a user is working with a Block rule and an Allow rule, the behavior is driven by evaluation of each rule, and the most restrictive outcome generally wins for the user experience.

Part 3: How It Works at Runtime

When Duplicate Rules Fire
Duplicate rules evaluate when a record is created or edited through the UI, the API (including Data Loader), and most automation paths. On edit, the rule only runs when a field referenced by the matching rule is actually changed; editing an unrelated field does not re-trigger duplicate detection.

Order of Execution
In the save order of execution, duplicate rules run after before-triggers and validation rules and before the record is committed and after-triggers run. If a Block action fires, the save fails and after-triggers, workflow, flows, and assignment rules never execute for that record.

Behavior by Entry Point
- Lightning Experience and Salesforce Classic UI: Alerts display with a list of potential duplicates; Block prevents save.
- API / Data Loader: Alerts cannot be shown interactively. If the action is Allow, the record is saved (and reported if Report is checked). If the action is Block, the API returns a DUPLICATES_DETECTED error and the row fails. This is why many admins add a condition excluding the integration profile, or set the action to Allow + Report for API users.
- Data Import Wizard: has its own built-in matching (by name, email, or ID) for deciding whether to update or insert, but org duplicate rules with Block will still cause rows to fail.
- Lightning Record Page: the Potential Duplicates component surfaces matches on existing records and offers a Merge path, even after the record is saved with Allow.

Situations Where Duplicate Rules Do NOT Run
Exam questions love these exceptions:
- Records created via Quick Create.
- Records restored from the Recycle Bin.
- Records created through Lead Conversion (the resulting account/contact/opportunity are not checked).
- Records created by Self-Service users or some Community/Experience contexts.
- Records added via merge operations.
- Records created by Lightning Sync / Einstein Activity Capture.
- When a Salesforce Apex test runs with certain settings, or when the rule is inactive.

Part 4: Reporting and Cleanup

Duplicate Record Sets and Duplicate Record Items
When a duplicate rule uses the Report option, each detected match is stored as a Duplicate Record Set (the group) containing Duplicate Record Items (the individual records). To report on them, create a custom report type with Duplicate Record Sets as the primary object and the related object (for example Accounts) as the child, or use the standard Duplicate Record Set reports. From a Duplicate Record Set you can select records and merge them.

Duplicate Jobs
Duplicate rules only catch records at creation or edit. To find duplicates that already exist, use Duplicate Jobs (available in Performance and Unlimited Editions, and in Lightning Experience). A duplicate job runs a selected matching rule across all existing records of an object and generates Duplicate Record Sets you can review and merge in bulk. This is the answer when a scenario says we have 50,000 existing accounts and want to find existing duplicates.

Merging
Standard merge is available for Accounts, Contacts, Leads, and Cases (and Person Accounts). You can merge up to 3 records at a time, choosing the master record and which field values survive. Related records are reparented to the master.

Part 5: Common Scenario Patterns and the Right Answer

- Prevent reps from saving a lead that already exists as a contact --> Duplicate rule on Lead with a Contact matching rule (cross-object), Action: Block or Allow with Alert.
- Warn users but let them proceed, and track how often it happens --> Allow with Alert and Report.
- Nightly integration keeps failing on duplicates --> Add a Condition excluding the integration user profile, or set Action to Allow for that path.
- Reps only see duplicates within their own region, but management wants org-wide prevention --> Set the duplicate rule to Bypass sharing rules.
- Nicknames and misspellings are slipping through --> Use the Standard matching rule or Fuzzy matching on name fields in a custom matching rule.
- Need duplicate prevention on a custom object such as Property__c --> Create a custom matching rule on the custom object, activate it, then create a duplicate rule.
- Find duplicates already in the database --> Duplicate Jobs (not duplicate rules).
- Cannot edit a matching rule --> It is active; deactivate it (and any dependent duplicate rules) first.
- Users want a customized warning message --> Edit the Alert Text on the duplicate rule.
- Two records with blank phone numbers are being flagged as duplicates --> Uncheck Match Blank Fields on that criterion.

Exam Tips: Answering Questions on Matching Rules and Duplicate Rules

Tip 1 - Always classify the question as find vs. act. If the question is about how records are compared (fuzzy, exact, which fields, blank handling), the answer involves a Matching Rule. If it is about what the user experiences (block, alert, report, who it applies to), the answer involves a Duplicate Rule. Many wrong answer choices swap these.

Tip 2 - Remember the dependency order. Matching rule first, activate it, then duplicate rule. Any answer that creates a duplicate rule before an active matching rule exists is wrong. Likewise, to edit a matching rule you deactivate the duplicate rule, then the matching rule.

Tip 3 - Know Block vs. Allow precisely. Block = cannot save, no Report option. Allow = saves, with optional Alert and optional Report. If the scenario mentions tracking, analyzing, or reporting on duplicates, the Report option (and therefore Allow) must be part of the answer.

Tip 4 - Watch for sharing language. Phrases like regardless of visibility, even records the user cannot see, or across the entire org point to Bypass sharing rules. Phrases like only within their own records point to Enforce sharing rules.

Tip 5 - Cross-object means Lead vs. Contact (or Account vs. Person Account). When a scenario asks to prevent leads for existing contacts, pick the duplicate rule on Lead that references a Contact matching rule with field mapping. There is no need for Apex.

Tip 6 - Integrations and bulk loads are a trap. Alerts do not display via the API or Data Loader. Block returns an error; Allow silently saves. The admin fix is a Condition on the duplicate rule (by profile or user) rather than turning off the rule for everyone.

Tip 7 - Existing data requires Duplicate Jobs, not rules. Duplicate rules are preventive and fire on save. Any question about cleaning up historic duplicates is answered by Duplicate Jobs plus merge, or by Report action plus Duplicate Record Set reports.

Tip 8 - Memorize the numbers. 5 active matching rules per object, 25 active matching rules per org, 10 fields per matching rule, 5 active duplicate rules per object, 3 matching rules per duplicate rule, 3 records per merge. Exam questions sometimes present an option that exceeds a limit as a distractor.

Tip 9 - Fuzzy is not universal. If an answer proposes fuzzy matching on an arbitrary custom text field, a long text area, or a picklist, it is wrong. Fuzzy is only for the predefined name, company, address, phone, email, and title-type fields; picklists are Exact only; long text, rich text, multi-select, formula, and encrypted fields are not supported at all.

Tip 10 - Know the exceptions list. Quick Create, Recycle Bin restore, Lead Conversion, and merges do not trigger duplicate rules. If a scenario asks why a duplicate got through and one of these is mentioned, that is the reason.

Tip 11 - Prefer declarative over code. The Advanced Administrator exam rewards choosing native Duplicate Management over Apex triggers, validation rules, or third-party AppExchange tools unless the question explicitly describes a requirement that native tools cannot meet (for example matching on unsupported field types or complex scoring).

Tip 12 - Eliminate by object. Standard matching and duplicate rules exist only for Account, Contact, Lead, and Person Account. For any custom object, the answer must involve creating a custom matching rule first.

Quick Recap
Matching rules define the comparison logic (fields, exact or fuzzy, blank handling, AND/OR equation) and must be active. Duplicate rules apply that logic on create and edit, choosing Block or Allow with Alert and/or Report, respecting or bypassing sharing, optionally limited by conditions, and optionally matching across objects. Reporting lives in Duplicate Record Sets; historic cleanup uses Duplicate Jobs and merge. Master the find-vs-act distinction, the limits, the sharing options, and the exceptions, and you will handle every Duplicate Management question the Advanced Administrator exam puts in front of you.