You’re three days from go-live. The migration is done, the data is in, and the client is running final validation. Then someone opens the Accounts list and starts scrolling.

Same company, three times. Different spellings, different owners, one with a phone number and two without. The client asks if this is normal. You say you’ll look into it.

You check the duplicate detection rules. They’re on. They’ve been on. You test one manually: create an account with a name that already exists, and the warning fires exactly as it should. The rules work.

So why are there duplicates?

This is the moment most CE consultants hit at least once. It’s not a misconfiguration. It’s not something you missed in the project checklist. It’s a structural gap in how native duplicate detection was built, and go-live week is precisely when that gap opens widest.

What native duplicate detection was built for

Native duplicate detection in Dynamics 365 CE does one thing reliably: it catches duplicates entered through the UI.

A user opens a new Contact form, enters an email address that already exists, clicks save, and the warning fires. They see the potential duplicate, review it, and decide whether to proceed. That workflow works. It was designed for exactly that scenario.

The rules themselves are flexible enough. You can match on email, phone, company name, and combinations of fields. You can scope them by entity. For a clean, UI-driven data entry workflow, native detection is a reasonable first line of defense.

The problem is that go-live week is not a clean, UI-driven data entry workflow.

Go-live week is when everything hits Dataverse at once

Go-live week typically involves some combination of the following landing in Dataverse in a short window:

• A legacy CRM migration pushing tens of thousands of records via bulk import or API
• A Dual-Write sync initializing Finance & Operations data into CE
• Power Automate flows activating for the first time and creating records from connected systems
• Marketing automation syncing contacts from a campaign platform
• Manual data entry from the team doing final cleanup

Native duplicate detection rules don’t fire on most of these. Bulk imports via the Web API bypass detection by default unless the integration explicitly opts in. Dual-Write sync doesn’t trigger the rules. Automated flows creating records don’t run detection unless they’re built to do so.

The rules that work fine in testing, where a consultant is manually creating records through the UI, are largely invisible to the actual data volume arriving at go-live.

The “Ignore and save” problem compounds it

Even for records that do trigger detection, entries made through the UI during go-live week, there’s a second failure mode.

When native detection fires, it presents the user with a warning and two options: review the potential duplicate or dismiss the warning and save anyway. The “Ignore and save” path requires one click. Under go-live pressure, with a team trying to get everything entered before the cutover deadline, that button gets clicked a lot.

There’s no enforcement mechanism. No way to require review before saving. No audit trail of how many warnings were dismissed. The detection ran; it just didn’t stop anything.

The bulk detection job has a ceiling

The standard response to discovering post-migration duplicates is to run a bulk duplicate detection job. Find what got through, merge, and clean.

The bulk detection job in Dataverse caps at 5,000 records.

On any mid-market migration, that ceiling is hit before you’ve touched most of the dataset. You’re running the job in batches, tracking what’s been processed, and managing a cleanup operation that expands the longer it runs, because new records are still arriving through active integrations while you’re working through the backlog.

This is not a detection strategy. It’s a cleanup operation with a known size limit, running against a dataset that isn’t standing still.

Why this keeps happening on every project

The pattern here isn’t bad luck or a misconfigured environment. It’s structural.

Native duplicate detection was built for one entry point: the Dynamics 365 UI. Every other entry point into Dataverse, the Web API, bulk imports, integration syncs, and automated flows, is architecturally separate, and each one bypasses detection by default unless someone explicitly builds around it.

On a typical CE project, the number of entry points multiplies as the implementation grows. The legacy CRM migration is one. The ERP integration is another. The marketing platform sync is a third. Each one requires its own configuration or workaround to enforce detection. Each one is a potential gap.

Go-live week is when all of those entry points activate simultaneously, with real data volume, under time pressure. It’s the worst possible moment to discover that native detection only covered one of them.

The fix isn’t more rules

Adding more duplicate detection rules doesn’t close this gap. The rules are fine; the problem is that they’re not running on the entry points that matter most during go-live.

The fixes that consultants typically reach for, setting the SuppressDuplicateDetection: false header on Web API calls, writing plugins on the Create message, running post-load cleanup scripts, each address one entry point at a time. On a project with four active integrations, that’s four separate solutions to maintain, each scoped to a specific connector or entity, each requiring re-implementation on the next project.

What closes the gap structurally is a deduplication layer that runs inside Dataverse itself, at the platform level, regardless of how a record arrived. One that covers standard and custom tables, works across all entry points, and doesn’t require per-integration configuration every time a new data source goes live.

What that looks like in practice

Plauti Deduplicate for Dynamics 365 installs from Microsoft Marketplace and runs entirely within the client’s Dataverse environment. It catches duplicates at every entry point, form saves, bulk imports, Web API calls, and integration syncs, without needing each one configured separately.

For partners, the practical difference is project scope. The duplicate workstream gets handled once during implementation, rather than re-surfacing as a go-live week fire drill on every engagement. The 5,000-record ceiling doesn’t apply. Custom tables are covered. And the configuration carries across projects rather than being rebuilt from scratch each time.

Go-live week should be about cutover confidence, not duplicate cleanup. The tool that gets you there is one that was running before the first record landed.

What to do before your next go-live

If you’re mid-project, map your entry points now, not during cutover week. For each one, check whether duplicate detection is actively running or relying on the UI default. The Web API header behavior alone accounts for a significant share of the duplicates that appear at go-live.

If you want to see how partners handle this across every project with a single consistent approach, book a 20-minute walkthrough with the Plauti team. No theater, just the specific configuration a CE consultant would actually set up.

The post Native D365 duplicate detection goes quiet exactly when you need it appeared first on CRM Software Blog | Dynamics 365.