Duplicate detection

What it does

Rules that compare a base record type against a matching record type on chosen columns, and warn the user — or list the matches in a job — when a new or changed row looks like an existing one. Model-driven and customer engagement apps ship with default rules for accounts and contacts; everything else you build yourself.

Key facts

A rule pairs a Base Record Type with a Matching Record Type. They're usually the same, but cross-type rules work — comparing Email on Contacts against Email on Leads, for example.
Criteria options per rule include Exclude inactive matching records, Case-sensitive and Ignore Blank Values, plus operators like Exact Match, Same First Characters and Same Last Characters.
Publishing a rule builds a matchcode for every row of the matching record type. You can have at most five published rules per base record type at a time.
The number of criteria you can add is bounded by the matchcode length, shown live as Current matchcode length at the bottom of the criteria list.
Detection is switched on separately at organisation level, with three independent triggers: when a record is created or updated, when Dynamics 365 for Outlook goes from offline to online, and during data import through the wizard.
Duplicates are explicitly not detected when a user merges two records, activates or deactivates a record, or saves a completed activity.
If a rule has only one condition, blank values are ignored during the detection job and the rule doesn't work offline.
Bulk duplicate detection jobs are scheduled separately under Settings > Data management > Duplicate detection jobs, can run on a recurrence, and can email you on completion.
Duplicate detection rules aren't triggered on calculated or formula columns.

When to use / skip

Turn it on for accounts, contacts and leads in any CRM implementation where humans type in data, because the default rules are cheap and the alternative is a data quality project in eighteen months. Use bulk jobs for periodic cleanup rather than relying on the create/update prompt alone, since the prompt is a warning users learn to click through. Skip it entirely if the table is populated exclusively by integration — matchcodes cost storage and write performance, and an integration should be enforcing uniqueness with an alternate key instead. Alternate keys are the right tool when you actually need to prevent duplicates; duplicate detection only tells you about them.

Configuration decisions

Which of the three triggers to enable, and specifically whether the create/update prompt is worth the friction it adds to every save.
Whether to compare like with like or across record types, which is where the real value sits — the Lead-to-Contact overlap is usually the client's actual problem.
How aggressive the criteria are, and therefore whether you're generating useful warnings or noise users dismiss reflexively.
Whether to build a scheduled bulk job and who acts on its output, because a job with no owner is a report nobody reads.
Whether uniqueness is a genuine business rule, in which case an alternate key belongs in the design as well.

Gotchas

Publishing a rule on a large table builds a matchcode for every single row. On a multi-million-row table that's a heavy operation — schedule it, don't fire it at 10am on a Tuesday.
The five-published-rules-per-base-type ceiling sneaks up on you, particularly on Account, where the shipped defaults already consume slots.
Merge doesn't run detection. Neither does activating or deactivating a record. Clients assume merging is where the platform checks hardest, and it's the opposite.
Detection doesn't fire on calculated or formula columns, so a rule based on a derived value silently does nothing.
Turning detection on with a large data volume has a documented performance impact. Microsoft says so plainly on the admin page, and it's worth quoting to whoever asked for it.

Consultant notes

The integration conversation is the one that matters. API-driven writes control detection through the SuppressDuplicateDetection parameter on the request, so a bulk load or a middleware integration can bypass the rules entirely — usually without anybody deciding that it should. Ask what your integration partner is sending.
Frame duplicate detection as an assistive warning and alternate keys as enforcement. Clients conflate them and then blame the platform when duplicates appear.
Get someone from the business to own the bulk job output before you build it. Data quality without an owner regresses within a quarter.
If the client's real complaint is duplicates arriving from a marketing list, the fix is upstream in the import process, not in Dataverse. Say so early.

Worth another look if the client adds an integration to a table that has published rules, or if bulk job runtimes start creeping up.