Duplicate detection rules

What it does

Duplicate detection compares a record against others using published rules and warns the user, or reports matches in a bulk job. Rules are defined per base table with a matching table, a set of field criteria and a few behaviour flags. Model-driven apps including Sales ship default rules for accounts and contacts; everything else you build yourself.

Key facts

Rules live in the Power Platform admin centre under the environment's Settings, Data management, Duplicate detection rules.
A rule needs a base record type and a matching record type. They can differ, which is how you catch a lead that duplicates an existing contact.
Criteria use operators such as Exact Match, Same First Characters and Same Last Characters, with a character count for the last two.
Three flags change behaviour materially: Exclude inactive matching records, Case-sensitive, and Ignore Blank Values.
A maximum of five published rules per base record type. Plan the set rather than accumulating them.
Rules must be published to take effect. Publishing builds match codes across the matching table, which takes time proportional to record volume.
To edit a published rule you unpublish it first. While it's unpublished, it isn't detecting anything.
The match code has a character limit, which caps how many criteria you can practically stack in one rule.
If a rule has a single condition, blank values are ignored during detection jobs and offline synchronisation.
Creating, editing and publishing rules needs System Administrator, System Customizer, Sales Manager, Vice President of Sales, Vice President of Marketing or CEO-Business Manager.
Detection fires when users create or update records in the app and during data import; it does not run offline. The newer detect-and-merge experience applies to manual data entry in the app, not to import.
Merge is supported for accounts, leads and contacts: pick a primary record, choose which values to keep, and the secondary is deactivated with its child records reparented.

When to use / skip

Turn on a small, well-chosen set of rules on almost every project. Duplicate accounts and contacts are the most reliable way to lose a client's confidence in a CRM, and the cost of two or three good rules is an afternoon.

Where to be sceptical is the client who wants fuzzy matching across ten fields. This engine is exact-match and prefix/suffix match on stored values — it is not a matching product. If the requirement is real deduplication across millions of records, or address normalisation, or probabilistic matching, the answer is a dedicated data quality tool feeding Dataverse, not more rules.

Also be careful before enabling detection on high-volume integration paths. A warning dialogue is meaningless to an integration, and publishing rules on a table with tens of millions of rows has a real cost.

Configuration decisions

Which tables get rules at all. Account, Contact and Lead are the usual three, and lead-to-contact cross-table matching is worth the extra rule.
The matching fields. Email address and a name plus postcode combination outperform name alone by a wide margin.
Whether inactive records are excluded, which decides if a closed lead blocks a new one.
Whether the rule set runs only at data entry, or also as a scheduled bulk detection job for ongoing hygiene.
What the merge process is and who is allowed to do it, since merge deactivates a record and moves children.
How data migration is sequenced against publishing — deduplicate the source data before load, or load and then run detection jobs.

Gotchas

Saving a rule does nothing. Unpublished rules are inert, and this is the most common "duplicate detection isn't working" call.
Publishing on a large table is a background job that can take a long time and will slow the environment while it runs. Do it out of hours.
Five published rules per base table is a hard ceiling. Clients who add a rule per requirement hit it and start deleting the good ones.
Detection warns; it does not block. A determined user clicks past it. If the business needs prevention, you need an alternate key or plugin logic, not this feature.
Integrations and most automated record creation don't surface a dialogue, so duplicates arrive through the back door while the front door is guarded.
Case sensitivity and blank handling change results in ways that are hard to reason about after the fact. Set them deliberately and write down why.
Merge is limited to accounts, leads and contacts. Duplicate opportunities are a manual clean-up problem.

Consultant notes

Test rules against a copy of real migration data, not invented test records. Client data is messier than anything you'd think to type.
Show the client the warning dialogue during UAT and be explicit that it's a warning. The "why didn't it stop them" conversation is better had early.
If duplicates are a stated business problem, put an alternate key on the one field that genuinely must be unique and use rules for the rest.
Schedule a bulk detection job monthly for the first few months post go-live and review the output with the client's data owner. It surfaces process problems, not just data ones.
Before go-live, confirm the rules are published in production. They frequently arrive from a solution or a copy in an unpublished state.

Worth another look after any large data migration, or if the client starts asking for fuzzy matching.