Duplicate lead detection

What it does

A Sales-specific duplicate check for leads that uses a matching model rather than the classic Power Platform duplicate detection rules. It flags likely duplicates on the lead form as the seller works, based on email, phone and fuzzy name-plus-company matching.

Key facts

Enabled at App Settings > Data improvement > Duplicate detection in the Sales Hub app, with a single Enable rules toggle.
The matching logic is fixed, not authored by you: same email address, same phone number, similar lead name plus company name, or similar lead name plus the same email domain.
It rides on Dataverse search, so Dataverse search has to be on in the environment. If search indexing is behind, detection is behind.
The columns used for matching must be present in the Find by section of the Quick Find All Leads view: firstname, lastname, emailaddress1, telephone1, companyname. Strip one out of quick find and that part of the matching quietly stops working.
Three processes need to be active for it to run: CheckForDuplicatesAction, DuplicateDetectionTriggerAction and GetDuplicatesAction. Users also need read access to Process under Customization.
Works on the out-of-the-box lead forms in Sales Hub and Sales Professional. Custom forms need a separate opt-in, documented on its own page.
If classic Power Platform duplicate detection rules for leads are also active, the app tells you so. Microsoft's guidance is to switch the classic lead rules off and pick one mechanism.
It is a detection and surfacing feature, not a merge engine. Merging is still the standard Dataverse merge, with all the usual field-level consequences.
Configuration needs an administration and customisation role; sellers just need the lead privileges they already have.

When to use / skip

Turn it on for any client whose leads arrive from more than one place — web forms, events, a marketing tool, a spreadsheet a sales manager keeps. Fuzzy name matching against company and email domain is meaningfully better than what most people build with classic rules, and it costs you a toggle rather than a rule-authoring workshop.

Skip it, or at least think harder, where the client has already invested in a carefully tuned set of classic duplicate detection rules covering leads, accounts and contacts as one story. Running both is confusing for sellers, and this feature only covers leads — you still need classic rules or something else for accounts and contacts, so you end up with two different mental models on adjacent forms. Also skip if the environment cannot have Dataverse search on, though that is rare enough now to be an edge case.

Configuration decisions

Whether this replaces the classic lead rules or the client keeps classic rules everywhere for consistency across entities.
What happens to the rest of the model: accounts and contacts still need their own duplicate story, and someone has to own that decision.
Whether custom lead forms are in scope, since they need the separate enablement step rather than inheriting it.
Whether quick find on the lead view is protected from customisation — the matching depends on those Find by columns staying put.
What sellers are expected to do when a duplicate is flagged: abandon, merge, or carry on and let a data steward sort it out later.
Whether a bulk deduplication pass on existing leads is in the project scope, because this feature will not clean up history for you.

Gotchas

Somebody adds a column to the Quick Find All Leads view during a later phase, removes one by accident, and detection degrades without any error anywhere. It is a genuinely silent failure.
The rules cannot be edited. Clients who want "match on postcode and surname" will be disappointed, and the answer is classic rules, not this.
Leads created through the API or an integration do not get the same interactive prompt sellers see on the form. Integrations still need their own matching logic.
Detection is not enforcement. Nothing stops a seller creating the duplicate anyway, which surprises anyone who expected a hard block.
Dataverse search latency means a lead created seconds ago may not be matched against. Bulk imports are the common trigger for this complaint.
Turning it on while classic lead rules are still published gives you two different duplicate experiences on the same form. Decide, then disable the other.

Consultant notes

Demo it with real duplicates from the client's own extract. The fuzzy name-and-domain match is the part that convinces people, and it does not land with made-up data.
Set expectations that this is a lead-only feature. Sales managers hear "duplicate detection" and assume accounts and contacts are covered.
Add the quick find view columns to your solution documentation and your go-live checks, because that dependency is invisible to whoever picks the system up after you.
Agree the merge policy with the client before enabling anything. Detection without an agreed response just adds a dialog sellers learn to dismiss.

Worth another look if Microsoft extends the model beyond leads or makes the matching rules configurable.