Rescuing a Failed Dynamics 365 Implementation: Name the Root Cause Before You Fix Anything
"Can this be saved?" is the wrong first question
Every rescue conversation opens the same way. The project is late, or live and wrong, the support team has quietly gone back to a shared mailbox and a spreadsheet, and someone senior wants to know whether to keep going or write it off. It is a fair question, and it cannot be answered yet, because nobody has said what is actually broken. Rescue budgets get burned on the wrong remediation far more often than on the wrong platform: a team convinced the problem is technical hires developers, who build on a data model that was wrong before anyone wrote code.
Three root causes, and why the difference is expensive
Almost every stalled Dynamics 365 or Power Platform project we assess fails for one of three reasons, often two at once.
Unowned requirements. The build reflects what somebody assumed the business needed, not how it works. The symptoms are recognizable: processes nobody follows, mandatory fields filled with junk to get past a form, a data model shaped around a sales demo, twenty change requests that are the same complaint reworded. More development does not help here.
Technical debt in the customizations. Plug-ins with logic buried in them and no tests, form JavaScript doing what a business rule should do, unmanaged layers stacked over managed ones, flows hard-wired to one person's connection. Every change breaks something else, so the team stops changing anything.
Misconfigured standard modules. The most common cause and the most fixable. Dynamics 365 already does the thing the project is failing at, but it was configured wrong or never configured, so the team built around it or gave up. Routing stuck on the default queue. SLAs pausing at the wrong moments. Security roles cloned until nobody can say who sees what. That is configuration work, not development, and usually the fastest win.
What an independent assessment inspects
An assessment reads the environment, not the story around it, so it needs read access, not a slide deck. The Dataverse model and relationships, forms, views, business rules, process flows. The Customer Service configuration especially: queues, routing, SLAs, entitlements, case settings, automatic record creation rules. Plug-ins, JavaScript, flows, and PCF components alongside the solution layering. Then security roles against who should see what, integrations including the ones that fail quietly, and the failures piling up in run history.
Global firms like Avanade sell Dynamics 365 health check services covering similar ground, and a good one is worth having. What differs with a small independent team is that we did not build the system under review and do not resell licenses, so no finding has an earlier decision to defend behind it. That inspection is the front end of our Dynamics 365 and Power Platform services, and the report is yours to act on with any partner.
The worked example: routing that was never turned on
A support team is drowning in email, everything lands in one queue, a lead triages it by hand each morning, and the conclusion is that the platform cannot route by topic. It can. Unified routing was never configured. The sequence below is the same whether you are setting it up fresh or repairing an inherited one.
Enable unified routing in the Customer Service admin center. It is the current intelligent routing engine and replaces the older rule-based routing built on basic queues. Then create a workstream, the container holding routing and distribution settings for one stream of work: messaging for live channels and email, record for cases, voice for calls. Set the distribution mode to push or pick, the capacity model, and the presence statuses an agent must be in to receive work. Type and distribution mode matter most, because everything hangs off them.
Attach the channel. For email, point the workstream at the mailbox receiving the traffic, and check first that it is approved and enabled for server-side synchronization. A mailbox that quietly failed test and enable stops email routing before any rule runs.
Then the part people skip. Work classification runs before anything reaches a queue: a rule set whose rules read the incoming item and stamp attributes onto it, such as topic, priority, or skills, by testing the subject, body, sender, or related columns. Classification routes nothing by itself, which is exactly why routing that looks correct on screen never fires. The attribute it tests was never set.
The route to queues rule set is the decision list that picks the destination, evaluated top to bottom until something matches. Put narrow rules above broad ones and finish with a catch-all pointing at a real fallback queue, because anything matching nothing drops into the workstream fallback queue and gets forgotten. Then create one queue per destination, add the users or teams who own it, and choose the assignment method: highest capacity, round robin, or a custom rule set for your own priority ordering. Skill-based routing is configured here, matched against the skills classification stamped earlier.
Finally, push real traffic through and read the diagnostics, which show which classification rule matched, which decision list rule chose the queue, and how assignment resolved. That is how you tell an unmatched condition from a mailbox problem from an agent capacity problem. Microsoft moves the admin center around between releases, so treat these names as the shape of the configuration, not a fixed menu path.
Routing email by topic: four patterns that work
Keyword and condition rules on the message are the right first move: transparent, maintainable as the vocabulary changes, and when something misroutes you can see which rule did it. Machine learning classification earns its place when the language is genuinely ambiguous, but it is a poor opening move, because a model layered over queues that are already wrong makes misrouting harder to explain. When topic depends on something outside the email, like the contract a customer is on, derive it in a flow or plug-in, write it to a column, and route on that. And where your process works cases rather than raw email, an automatic record creation rule can convert mail into cases routed through a record workstream, so topic lives on the case where SLAs and reporting use it. Pick one early, and shape the queues around how the team is actually organized: queues that mirror the team beat an elaborate rule set feeding queues nobody owns.
What to take away
- Diagnose before you spend. The three root causes look similar from outside and need completely different remediation, and configuration fixes come first. - In unified routing, classification stamps attributes and the decision list acts on them. Most broken routing fails because classification never set the attribute, or there is no catch-all at the bottom. - Check the mailbox before the rules, and document the workstreams, rule sets, and queues afterwards. Undocumented routing drifts back into trouble the first time the team reorganizes.
A rescue is not a restart. If your implementation has stalled, whether it is a professional services desk or a sales team that gave up, and you want an independent read on what is wrong, that is the conversation our services are built to start.
Most failed Dynamics 365 projects fail for one of three reasons - unowned requirements, technical debt in the customizations, or standard modules that were misconfigured or never configured at all - and each needs a completely different remediation. The third cause is the most common and the cheapest to fix, and Customer Service routing is the clearest example of it.
Frequently Asked Questions
What do Dynamics 365 rescue services actually involve?
An independent partner takes over a failed or stalled implementation and remediates it. The sequence is an assessment that names the root cause, whether that is unowned requirements, technical debt in the customizations, or standard modules that were misconfigured or never configured, then stabilization of the environment, then a prioritized remediation plan, then takeover of delivery. The aim is to protect what has already been built and fix only what is genuinely broken, and to say so plainly where part of a design cannot be salvaged.
Can Dynamics 365 route emails automatically by topic?
Yes, and it is configuration rather than custom development. In Customer Service with unified routing it happens in two stages. Work classification rules run first and stamp a topic onto the work item, from keyword and condition rules on the subject, body, sender, or related records, from a machine learning classification model, or from a column your own flow or plug-in derived. The route to queues rule set then evaluates its ordered decision list and sends each topic to the queue that owns it. If your process works cases rather than raw email, an automatic record creation rule converts mail into cases and a record workstream routes those instead.
What is the difference between a workstream, a routing rule set, and a queue?
A workstream is the container for one stream of work such as email, cases, or calls, and it holds the work distribution mode, capacity model, and routing configuration. Routing rule sets live inside a workstream and come in two kinds: work classification rule sets, which run first and enrich the item with attributes like topic, sentiment, or skills, and the route to queues rule set, which is an ordered decision list that picks the destination queue. A queue is where work waits and gets assigned, with its own membership and assignment method such as highest capacity or round robin.
How does an independent assessment differ from a large integrator health check?
The scope of the inspection is broadly similar, and health check services from firms like Avanade cover the same ground: configuration, customizations, security, performance, and adoption. The differences are independence and size. Solzet did not build the system under review and does not resell licenses, so no finding is shaped by an earlier decision to defend or an upsell attached to it. We are a small Dynamics 365 Customer Engagement and Power Platform team in Yerevan, so the people writing the assessment are the people who would do the remediation, and the report is yours to act on with any partner or with your own team.