You close out a migration. The duplicate workstream took longer than scoped; it always does, but you got there. Post go-live, the data looks clean. The client signs off.
Six months later, a new project kicks off. Different client, similar stack. Legacy CRM, a couple of integrations, Dual-Write. The project plan goes up on the board, and somewhere in week three, someone flags duplicates in the migrated data.
You know exactly what to do. You’ve done it before. You write the plugin, set the header, run the cleanup job. It works. The client signs off.
Then it happens again on the next one.
At some point, the question stops begin “how do we fix this” and starts being “why are we fixing this the same way every time?”
The workaround that travels with every project
Most Dynamics 365 CE partners have a version of the same solution. It looks something like this:
A plugin registered on the Create message for the entities that matter most: Account, Contact, Lead. A header flag set on the primary integration connector. A post-migration bulk detection job to catch what got through. Maybe a Power Automate flow for ongoing deduplication between syncs.
It works well enough; it was built by someone who understood the problem. It gets copied from project to project, adjusted for the new client’s entity model, and deployed. And it does the job.
The problem isn’t that it doesn’t work. The problem is what it costs to maintain it at scale, and what happens the moment the project deviates from the template it was built for.
What “rebuilding it” actually means
Rebuilding the workaround on a new project isn’t just copy-paste. Each implementation involves:
Entity scope decisions. The plugin covers Account, Contact, and Lead on the last project. This client has three custom entities that feed into the same deduplication problem. Someone has to decide whether to extend the plugin, write new ones, or leave those entities uncovered and document the gap.
Integration-specific configuration. The header flag works on KingswaySoft. The new project uses a different ETL tool or a custom Web API client that the integration team built in-house. The configuration isn’t transferable. Someone has to find the equivalent setting, or discover there isn’t one.
Environment deployment. The solution needs to be packaged, deployed into the client’s environment, tested, and handed over. That’s billable time on every project, for a problem that hasn’t changed since the last one.
Post-migration cleanup. The bulk detection job still caps at 5,000 records. The dataset is larger than that. The batching process has to be managed manually, and someone has to track what’s been processed while new records arrive through active integrations.
All of this takes time. And all of it gets scoped, estimated, and delivered again on the next project, and the one after that.
The cost that doesn’t show up in the project budget
The direct cost is visible: hours spent on duplicate workstream tasks that appear on timesheets and get billed or absorbed depending on how the project is scoped.
The indirect cost is harder to see but larger over time.
Every hour spent rebuilding a known solution is an hour not spent on the work that differentiates your practice. Configuration, data modeling, business process design; the work clients pay for and remember. Duplicate detection is infrastructure. It should behave like infrastructure: configured once, running in the background, not requiring a project workstream on every engagement.
There’s also the knowledge dependency problem. The person who built the original workaround knows how it works. When they’re on a different project, on leave, or no longer at the firm, the next person inherits something that was never documented as a product, because it wasn’t supposed to be a product. It was a workaround.
Why the workaround never becomes a product
The natural response to this pattern is to productize the workaround. Package it as an internal tool, maintain it properly, deploy it consistently. Some larger practices have done exactly this.
The problem is that the workaround is built on top of native Dataverse behaviors that weren’t designed for this use case. The plugin approach requires maintenance every time Microsoft updates the platform. The header flag approach is dependent on the calling system, and every new integration is a new dependency. The bulk detection job ceiling isn’t something you can engineer around; it’s a platform limit.
You can invest in making the workaround more reliable. You can’t make it not a workaround.
What changes when you stop rebuilding
The alternative isn’t a more sophisticated workaround. It’s a deduplication layer that runs inside Dataverse at the platform level: one that doesn’t depend on individual integration configuration, doesn’t require per-entity plugin maintenance, and doesn’t hit a ceiling on bulk jobs.
Plauti Deduplicate for Dynamics 365 CE installs from Microsoft Marketplace and runs within the client’s Dataverse environment. It covers all entry points, UI, Web API, bulk imports, and integration syncs, without requiring each one to be configured separately. Standard and custom tables are covered out of the box. There’s no 5,000-record ceiling.
For partners, the practical shift is that the duplicate workstream stops being a project deliverable and starts being an implementation step. Install, configure once for the client’s data model, and move on. The configuration is consistent across engagements rather than rebuilt from scratch each time.
That’s the difference between a workaround and infrastructure.
What to do differently on the next project
Before the duplicate workstream gets scoped on your next migration, it’s worth asking how much of what you’re planning to build is solving a new problem versus re-solving the same one.
If the answer is mostly the same one, the entry points are familiar, the entity coverage is familiar, the cleanup process is familiar, that’s the signal that the workaround has run its course.
To see how partners have replaced the rebuild cycle with a single consistent approach, book a 20-minute walkthrough with the Plauti team. No theater, just the specific configuration a Dynamics 365 CE practice would actually deploy.
The post D365 CE partners keep rebuilding the same duplicate detection fix. Nobody seems to mind. They should. appeared first on CRM Software Blog | Dynamics 365.