Matching Rules
A Matching Rule is the Salesforce setting that tells the platform how to compare two records and decide whether they are the same.
Definition
A Matching Rule is the Salesforce setting that tells the platform how to compare two records and decide whether they are the same. Each rule lists the fields to compare, the method to use on each field (exact or fuzzy), and a matching equation that combines those fields with AND and OR logic. It is the engine inside Duplicate Management that produces the actual match.
A Matching Rule does nothing on its own. You pair it with a Duplicate Rule, which decides what happens when a match is found, or you reference it from a Duplicate Job that scans existing records in batch. Salesforce ships standard Matching Rules for Accounts, Person Accounts, Contacts, and Leads. You can build custom rules for any object, including cross-object rules so a Lead can match against existing Contacts.
How matching actually decides a record is a duplicate
Match keys, then the matching equation
Running a full field-by-field comparison against every record in the org would be slow, so a Matching Rule works in two passes. First it uses match keys, which are normalized values generated from the fields in your rule. The match key narrows the candidate set to roughly the 100 most likely records. Only then does the rule apply the full matching equation to those candidates and score each field. This two-step design is why matching feels fast even in large orgs, and it is also why a poorly chosen field can quietly hurt accuracy. If the match key step does not surface a real duplicate among the top candidates, the equation never gets to evaluate it. When you design a rule, lead with fields that genuinely identify a record (email, company, last name) so the match key does useful filtering. Avoid building rules around low-signal fields that scatter the candidate set. The match key is generated automatically from your criteria, so you do not configure it directly, but understanding that it exists explains a lot of matching behavior.
Exact versus fuzzy, and why you cannot mix them
Each field in a rule uses one matching method. Exact matching looks for values that are identical after normalization, and it works on almost any field type including custom fields. Fuzzy matching looks for values that are close but not identical, which catches typos and common variations. The important rule is that a single Matching Rule must use either fuzzy or exact methods, not both. If you combine the two types in one rule, duplicates are not detected at all. When you need exact logic on some fields and fuzzy logic on others, split them into separate rules. Exact matching is the right default for international data, because fuzzy methods only support Latin characters and lean on hard-coded dictionaries that can behave oddly outside English-language data. A practical pattern is one exact rule keyed on Email, plus a separate fuzzy rule keyed on name and company, both referenced from the same Duplicate Rule. That keeps each rule internally consistent while still covering several ways the same person might be entered.
Specialized fuzzy methods and their thresholds
Fuzzy matching is not one algorithm. Salesforce provides field-specific methods tuned to how each kind of data varies, each with its own match threshold on a 100-point scale. First Name uses Jaro-Winkler plus a Name Variant lookup with an 85 threshold, so Bob and Robert can score as a match. Last Name uses Keyboard Distance and Metaphone 3 with a 90 threshold. Company Name strips noise words like Inc and Corp, expands known acronyms (IBM to International Business Machines), and matches at a 70 threshold. Phone splits the number into international code, area code, the next three digits, and the last four, weighting them 10, 50, 30, and 10 percent, and works best on North American data. Street address sections the value into name, number, suffix, and suite weighted 50, 20, 15, and 15 percent. ZIP weights the first five digits at 90 percent. Each method then rolls field scores into a single result using a scoring method (Average, Maximum, Minimum, or Weighted Average) and compares it to the threshold. Choosing the specialized method that fits the field beats generic fuzzy almost every time.
The matching equation and blank fields
The matching equation is where you decide how individual field comparisons combine. You can add up to 10 fields to a rule and join them with AND and OR. A typical Lead-to-Contact equation reads Email exact OR (Last Name fuzzy AND Company Name fuzzy). AND tightens the rule and reduces false positives, while OR widens it and catches more potential duplicates. Small edits to this equation move the false-positive rate a lot, so change it deliberately and test against real data. Each field also carries a Match Blank Fields option. When it is on, two records whose values are both blank count as a match on that field. When it is off, a blank never matches. Leaving it on can produce surprising matches, because many records share empty optional fields. There is one subtle trap: when the same fuzzy field appears in multiple OR segments, Salesforce only evaluates the segment closest to the end of the equation. To avoid skipped logic, build a separate rule for each OR segment that reuses the same fuzzy field rather than cramming them into one equation.
Standard, custom, and cross-object rules
Salesforce gives you standard Matching Rules for Accounts, Person Accounts, Contacts, and Leads, with logic appropriate for typical B2B sales data. Those standard rules cover the most common scenarios with no setup beyond activation. For everything else, including custom objects, you create custom rules. The most valuable custom rules are usually cross-object: a rule that lets a new Lead match against existing Contacts or Accounts is the basis of the Lead-to-Contact duplicate detection most sales teams want. Cross-object rules need careful field mapping, because the compared fields have to mean the same thing on both objects. Email on Lead and Email on Contact line up cleanly. Matching a Lead Company to an Account Name is the standard cross-object pairing. One constraint to remember is that a single Matching Rule allows only one lookup relationship field, so you cannot lean on multiple relationship fields to disambiguate. Plan the comparison around the natural identifying fields of each object instead, and keep cross-object rules tightly scoped to the fields that actually establish identity.
Limits, activation, and performance
Matching Rules carry several hard limits worth memorizing before you design them. Each object allows up to 5 active rules. Across the whole org you can have up to 25 active rules and up to 100 rules total counting both active and inactive. You can activate or deactivate up to 5 rules at once, and a Duplicate Rule can reference up to 3 Matching Rules. Activation is not instant. When you activate a rule, Salesforce builds the matching index in the background, and you get an email when the rule is ready to use. Plan activations for off-peak hours so the work does not collide with heavy user activity. On the performance side, matching runs on save for real-time Duplicate Rules and in batch for Duplicate Jobs. Including too many fields, or fields with very high cardinality, can slow record saves that users feel directly. The discipline is to include only fields that genuinely identify a duplicate, not every field that could conceivably overlap. Hitting the 5-rule cap on an object is usually a sign that the rules need consolidating rather than a sign you need more rules.
Encryption, sharing, and other gotchas
A few platform interactions catch teams off guard. Shield Platform Encryption only works with matching when the field uses deterministic encryption, and Duplicate Jobs are not supported on encrypted data at all, so an encryption rollout can silently change what your rules can see. Person account values placed in a Contact lookup field stop a rule from applying; use an Account lookup field instead. Hierarchy records add a merge restriction: you cannot merge when the chosen master record sits below one of the selected duplicates in the hierarchy. Creating, editing, deleting, activating, and deactivating Matching Rules all require the Customize Application permission, which keeps rule design in admin hands. Finally, treat rule names and descriptions as metadata that may be visible in exports and audit trails, so keep personal data out of them to stay clean under privacy regulations. None of these is a blocker on its own, but each one explains a class of "the rule did not fire" tickets that are easy to misdiagnose as a logic problem when the real cause is a platform constraint.
Create and activate a custom Matching Rule
Build a custom Matching Rule when the standard rules do not cover your object or your definition of a duplicate. You create and shape the rule first, then activate it, then reference it from a Duplicate Rule so it actually runs on save.
- Open Matching Rules in Setup
In Setup, use Quick Find to open Matching Rules. Make sure any rule you intend to edit is inactive first, because active rules are locked from changes.
- Create the rule and pick the object
Click New Rule, choose the object the rule applies to, and give it a name and description. Keep personal data out of both fields.
- Add matching criteria
Add up to 10 fields to compare. For each field, choose a matching method (exact or fuzzy) and set the Match Blank Fields option. Use only fuzzy or only exact in a single rule, never both.
- Build the matching equation
Combine the fields with AND and OR to express your duplicate logic, for example Email exact OR (Last Name fuzzy AND Company Name fuzzy). Tighten with AND, widen with OR.
- Save and activate
Save the rule, then activate it. Salesforce builds the index in the background and emails you when it is ready. Finally, reference the rule from a Duplicate Rule so it runs.
The object the Matching Rule applies to. Drives which fields are available and which records it scans.
A label for the rule. Avoid personal data, since it can surface in exports and audit trails.
Up to 10 fields to compare, each with a matching method and a Match Blank Fields setting.
The AND/OR expression that combines the field comparisons into the rule's overall match logic.
- A rule must use either fuzzy or exact methods. Mixing both in one rule means no duplicates are detected.
- Activation runs in the background and is not instant. Wait for the confirmation email before relying on the rule.
- Each object caps at 5 active rules, the org caps at 25 active and 100 total, and a Duplicate Rule references at most 3 Matching Rules.
- When the same fuzzy field appears in multiple OR segments, only the last segment is evaluated. Split those into separate rules.
- A Matching Rule allows only one lookup relationship field, which limits how much cross-object disambiguation you can pack into a single rule.
Prefer this walkthrough as its own page? How to Matching Rules in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Things to Know About Matching RulesSalesforce
- Matching Methods Used in Matching RulesSalesforce
Straight from the source - Salesforce's reference material on Matching Rules.
- Customize Matching RulesSalesforce
- Things to Know Before You Customize Matching RulesSalesforce
Hands-on resources to go deeper on Matching Rules.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What do Matching Rules define in Salesforce Duplicate Management?
Q2. Which comparison methods can a Matching Rule apply to a field?
Q3. How many active Matching Rules can a single object have?
Discussion
Loading discussion…