A matching rule defines what counts as a duplicate, and a duplicate rule decides what to do about it. You need both, the matching rule must be activated separately, and the whole feature is bypassed by most API inserts unless you explicitly ask for it. That last point is why orgs with duplicate rules still fill up with duplicates.
The two objects, and why there are two
Matching rule defines the comparison: which fields, and how exactly they must match. Salesforce provides standard ones for Account, Contact and Lead that use fuzzy matching on name and exact matching on email.
Duplicate rule points at a matching rule and says what happens on a match: Allow with an alert, Allow silently and record it, or Block. It also decides whether to compare against records the user cannot see.
Separating them means one matching rule can serve several duplicate rules with different actions for different conditions. It also means activating a duplicate rule while forgetting the matching rule, which produces a rule that matches nothing.
Fuzzy matching, and what it actually does
The standard matching methods are more capable than people expect:
- Exact compares character for character after normalising case and whitespace.
- Fuzzy: First Name knows that Bob and Robert are the same person, and Bill and William.
- Fuzzy: Last Name handles common misspellings and transpositions.
- Fuzzy: Company Name strips Inc, Ltd, Corporation and similar, so “Acme Ltd” matches “Acme”.
- Fuzzy: City and Fuzzy: Street handle abbreviations, so “St” matches “Street”.
Within a matching rule, conditions are joined by AND across fields, and you can add OR groups. A rule requiring email AND last name is precise and misses anyone who changed email. A rule on last name alone matches every Smith.
The API blind spot
Duplicate rules run for the UI, and for API operations only when the request asks. In Apex:
Database.DMLOptions opts = new Database.DMLOptions();
opts.DuplicateRuleHeader.AllowSave = false;
Database.insert(records, opts);Without that, an Apex or API insert creates duplicates regardless of the rule, and Data Loader has a setting for it that is off by default. So the honest position for most orgs is that duplicate rules protect the UI and nothing else, which is worth knowing before anyone claims the org is protected.
Block or alert
Blocking is tempting and it causes support tickets. A user with a legitimate reason to create a similar record is stopped with no route forward, and the workaround they invent is usually worse than the duplicate.
Alert with a required reason is the better default for most business objects: the user sees the potential duplicates, can open them, and proceeds deliberately. Reserve blocking for records where a duplicate is genuinely unrecoverable, and give those users a permission that bypasses it for the cases the rule gets wrong.
Reporting on what it found
Every match creates a DuplicateRecordSet with DuplicateRecordItem children, and those are reportable. A weekly report on new duplicate record sets tells you whether the rules are tuned correctly, which is otherwise invisible.
If the report is empty, the rules are matching nothing and probably need loosening. If it has hundreds of entries a week, they are too loose and users are ignoring the alert, which is the same as having no rule.
Existing duplicates
Duplicate rules prevent new ones. They do nothing about the 40,000 already in the org. That is a separate job: Duplicate Jobs will scan an object and produce record sets for review, available on some editions, and merging is manual or done through the API.
Merging loses data. The losing record’s field values are discarded except where the master is blank, and related records move but activities and notes behave differently per object. Export both records before a bulk merge.
Rules that fire only in the UI are a governance problem as much as a technical one, since the org can be described as protected while every integration writes around them. The tiering that handles this is in a governance model that does not become a bottleneck.
Frequently asked
Can I write a custom matching rule? Yes, on standard and custom objects, using up to ten fields.
Do rules work across objects? Only Lead against Contact and Lead against Account, which are built in. Custom cross-object matching is not supported.
Why does my rule not activate? The matching rule has to finish indexing first, which takes time on a large object. The duplicate rule cannot activate until it does.
