Dynamics 365 Rescue Services: How to Fix a Failed or Stalled Implementation
A technical guide to remediating a Dynamics 365 Customer Engagement or Power Platform project that has stalled, including how an independent assessment finds the root cause and a worked remediation of Customer Service unified routing.
This guide explains the step by step process for rescuing a failing Dynamics 365 Customer Engagement (CE) or Power Platform project. We detail how our independent assessment identifies root causes, whether poor requirements, technical debt, or misconfigured modules, and our method for taking over delivery to get the project back on track, based on real rescue engagements from our Yerevan team. Solzet is a Microsoft Dynamics 365 Customer Engagement and Power Platform consultancy headquartered in Yerevan, Armenia. Taking over work another partner or an internal team could not finish is a routine part of what we do, directly for end clients and on a white-label basis for other Microsoft partners.
A rescue is not a restart. The goal is normally to protect the investment already made, keep the parts of the build that are sound, and remediate only what is genuinely broken. We find out what is actually wrong first, make the system safe to run and safe to change, then deliver against a plan you can see. Where an assessment shows part of the design cannot be salvaged, we say so plainly and scope the smallest rebuild that gets you to a working solution.
The three root causes behind most failed implementations
Almost every stalled Dynamics 365 project we assess fails for one of three reasons, often more than one at once. Naming the right one matters, because the remediation for each is completely different and the wrong remediation burns the rest of the budget.
Poor or unowned requirements
The build reflects what someone assumed the business needed rather than how it works. Symptoms are recognizable: processes that nobody follows, mandatory fields people fill with junk to get past a form, a data model shaped around a demo instead of the real entities, and a backlog of change requests that all say the same thing in different words. No amount of extra development fixes this, because every increment is built on the same wrong picture. Remediation starts by re-establishing the real process and the decisions the system is supposed to support, then reshaping the model and the apps around it.
Technical debt in customizations and code
Plug-ins with business logic buried in them and no tests, JavaScript on forms doing what a business rule or a column should do, unmanaged solution layers stacked over managed ones, flows duplicated per environment with connections hard-wired to one person, missing or broken solution and deployment discipline, and PCF or canvas components left half-finished. The visible effect is that every change breaks something else, so the team stops changing anything. Remediation means untangling the layers, moving logic to where the platform expects it, and getting solutions and deployment into a state where a change can be released without guesswork.
Misconfigured out of the box modules
The most common and most fixable cause. Dynamics 365 already does the thing the project is failing at, but it was configured wrong or never configured at all, so the team built around it or gave up on it. Customer Service routing that never got past default queues, SLAs and entitlements that pause and warn at the wrong moments, business process flows that do not match the stages the business actually uses, security roles cloned until nobody can say who sees what, and duplicate detection or auto record creation rules that were switched on and never tuned. Remediation here is configuration work, not development, and it is usually the fastest visible win in a rescue.
The rescue process, step by step
The same sequence every time: assess independently, stabilize, agree a plan you can see, take over delivery in visible increments, and hand back a system your team can own.
Independent assessment of the real system
We examine the environment itself rather than the story around it, normally with read access to the solution, the Dataverse model, the customizations, and the run history of flows and plug-ins. We interview the people who use it and the people who built it. The output is a written diagnosis: what is sound, what is broken, what is missing, and which root causes are producing the symptoms you can see. Because we are independent of whoever delivered the project, the diagnosis is not shaped by a need to defend earlier decisions.
Triage and stabilization
Before anything new is built we make the system safe to run and safe to change: stop the failures that lose data or block daily work, contain the riskiest customizations, correct security roles that expose or hide the wrong records, and get environments, solutions, and source control into a state where a release can be made deliberately. Stabilization buys the team room to breathe and stops the situation getting worse while the plan is agreed.
A remediation plan tied to business outcomes
From the assessment we build a prioritized plan: the specific fixes, the order to do them in, what we keep, what we rework, and what, if anything, has to be rebuilt. Each item is tied to an outcome the business recognizes so you can see why it matters and what done looks like. Configuration fixes to misconfigured modules usually come first because they are fast, low risk, and visible to users. Where part of the design cannot be salvaged, the plan says so and scopes the smallest rebuild that reaches a working solution.
Takeover of delivery in visible increments
We take over delivery and work through the plan in short increments, correcting the model driven and canvas apps, repairing or rewriting flows and code, fixing integrations, and finishing the functionality the project was supposed to deliver. You see working software regularly instead of waiting for one distant go live, and each increment is tested against the real process it supports. Where your original partner is still involved, we can work alongside them on an agreed split rather than replacing them.
Handover, documentation, and ownership
A rescue is finished when your team can run the system without us. We document how the solution is built and why, leave a clean solution and deployment approach behind, and transfer knowledge to your people. You end with a working, supportable Dynamics 365 and Power Platform solution and the documentation to own it, whether we stay on for ongoing support or step away.
What the independent assessment inspects
The assessment is an evidence based read on the state of the environment, run with read access to the real system. It is the same inspection whether it is bought on its own as a health check or as the first step of a rescue.
Requirements and process fit
We compare what was built against how the business actually works today: the processes people follow, the decisions the system is meant to support, and the places where users have quietly routed around it. Where documented requirements exist we test them against reality rather than taking them at face value.
Configuration of the standard modules
Dataverse tables and relationships, forms, views, business rules and business process flows, and the Customer Service configuration in particular: queues, routing, SLAs, entitlements, case settings, automatic record creation rules, and knowledge management. We record what is configured, what is default, and what was rebuilt in code that the platform already provides.
Customizations, code, and solution hygiene
Plug-ins, custom APIs, JavaScript, Power Automate flows, and PCF or canvas components, read alongside the solution layering, environment strategy, and deployment approach. This is where we find the technical debt that makes the system expensive to change and risky to release.
Security, data quality, and integrations
Security roles, teams, and business units against who is supposed to see what, data quality and duplication in the tables the business depends on, and the integrations and connectors that move data in and out, including the ones that fail quietly and lose records.
Performance and platform health
Slow forms and views, synchronous logic doing work that belongs in the background, flow and plug-in failures accumulating unnoticed, storage and capacity, and the platform level settings and updates the environment is behind on.
Delivery and ownership
How work is prioritized, tested, and released, what documentation exists, and who inside your organization can actually own the system afterwards. A rescue that ends with a working system nobody understands has only moved the problem.
If you only need the diagnosis, the same inspection is available on its own as a Dynamics 365 health check and technical audit. If you already know what is wrong and need someone to assume control of delivery, that is our project rescue and takeover service.
Worked remediation: Customer Service unified routing
Misconfigured out of the box modules are the most common root cause we find, and routing in Dynamics 365 Customer Service is the clearest example. Teams reach a rescue with cases and email landing in one default queue and being triaged by hand, convinced the platform cannot do it, when unified routing was simply never configured. This is the configuration sequence we work through, and it is the same sequence whether you are setting routing up for the first time or inheriting someone else's configuration and fixing it.
Turn on unified routing in the Customer Service admin center
Unified routing is the current intelligent routing engine for Dynamics 365 Customer Service and Omnichannel for Customer Service, and it replaces the older rule based routing built on basic queues and routing rule sets. In the Customer Service admin center, open the routing settings under service configuration and enable unified routing. Provisioning takes a few minutes and adds the workstream, work classification, and assignment configuration used by every step below. Many stalled Customer Service projects are still running on default queues because this was never switched on.
Create a workstream for the channel you are routing
A workstream is the container that holds routing and work distribution settings for one stream of work. In the Customer Service admin center, go to Workstreams and create a new one. Give it a name, choose the type that matches what you are routing, which is a messaging workstream for live channels and email, a record workstream for records such as cases, or a voice workstream for calls, then set the work distribution mode to push or pick, the capacity model, and the allowed presence statuses agents must be in to receive work. Getting the type and distribution mode right here matters more than anything you configure later, because everything else hangs off the workstream.
Attach the channel and its account to the workstream
For email routing, add the email channel to the messaging workstream and point it at the queue mailbox or shared mailbox that receives the traffic. The mailbox has to be approved and enabled for server side synchronization and mail processing before anything routes, and a mailbox that fails its test and enable step is the reason a large share of email routing problems never reach the routing rules at all. For record routing of cases created from email, the automatic record creation rule that turns those emails into cases is configured separately and feeds the record workstream.
Add work classification rule sets to enrich the work item
Work classification runs first, before anything is sent to a queue. Inside the workstream, create a work classification rule set and add rules that read the incoming work item and stamp attributes onto it that later rules can act on. Rules can test the subject, the description, the sender, the customer record, or related columns, and they can also call machine learning models for sentiment, effort, or a custom classification model where you have one. This is the step where topic detection belongs. Classification does not route anything by itself, which is why routing that looks correct sometimes never fires: the attribute the routing rule tests was never set here.
Build the route to queues rule set that picks the destination queue
In the same workstream, create the route to queues rule set. This is a decision list: an ordered set of rules, each with a condition and a destination queue, evaluated top to bottom until one matches. Conditions can use anything on the work item, including the attributes set during work classification, so a topic captured in the previous step becomes the condition that selects the queue here. Order is significant. Put narrow, specific rules above broad ones and finish with a catch all rule pointing at a fallback queue, because a work item that matches no rule lands in the workstream fallback queue and is easy to lose.
Create the queues and their assignment rules
Create one queue per destination in your decision list, of the type that matches the workstream, and add the users or teams who work it as queue members. Then set how items are assigned inside the queue: highest capacity, round robin, or a custom assignment rule set where you need priority and skill ordering of your own. Skill based routing is configured here too, by attaching skills to the work item during classification and having assignment match them against agent skills. A clean set of queues that mirrors how the support team is actually organized is worth more than an elaborate rule set that routes into queues nobody owns.
Test with real traffic and read the routing diagnostics
Send genuine sample traffic through the channel and follow each item through the diagnostics in the Customer Service admin center, which show which classification rules matched, which decision list rule selected the queue, and how the item was assigned. This is how you tell an unmatched condition apart from a mailbox problem or an agent presence and capacity problem, and it is the fastest way to inherit someone else routing configuration and find out what it really does. Then document the workstreams, rule sets, and queues, because undocumented routing drifts back into trouble the first time the team reorganizes.
Microsoft moves the Customer Service admin center around between releases, so treat the names above as the shape of the configuration rather than a fixed menu path, and check the current Microsoft Learn documentation for unified routing for the exact location in your version.
Can Dynamics 365 route emails automatically by topic?
Yes. With unified routing in Omnichannel for Customer Service, topic is decided during work classification and acted on by the route to queues decision list. There are four patterns that work, and the choice between them is the whole design decision.
Keyword and condition rules on the message itself
The simplest approach, and usually the right first one. Work classification rules test the subject, body, sender domain, or a related customer or product record for the terms that identify a topic, and stamp the topic onto the work item. The route to queues decision list then sends each topic to its own queue. It is transparent, it is easy for your own team to maintain as the vocabulary changes, and when it misroutes something you can see exactly which rule did it.
Machine learning classification for messier language
Where topics are not separable by keywords, unified routing can call machine learning during classification, including the built in sentiment and effort models and a custom classification model where you have one available. Models earn their place when the text is genuinely ambiguous. They are a poor first move on a rescue, because a model layered over queues and rules that are already wrong just makes the misrouting harder to explain.
A topic column stamped by your own logic
When the topic depends on something outside the email, such as the contract the customer is on, the product they own, or a lookup in another system, the reliable pattern is to derive it with a Power Automate flow or a plug-in, write it to a column on the case or the work item, and let the routing rules test that column. The routing configuration stays simple and readable, and the business logic lives somewhere you can test it.
Route the case rather than the email where a case is the unit of work
If your support process works cases rather than raw email, let an automatic record creation rule convert inbound mail into cases and route those cases through a record routing workstream. Topic then lives on the case, where SLAs, entitlements, and reporting can all use it as well. Choosing between routing the message and routing the case early avoids the half configured setup where both are partly in play and neither works properly.
Frequently Asked Questions
What are Dynamics 365 rescue services?
Rescue services are an engagement where an independent partner takes over a failed or stalled Microsoft Dynamics 365 or Power Platform implementation and remediates it to a working state. The sequence is an independent assessment that identifies the root causes, whether poor requirements, technical debt, or misconfigured modules, then stabilization of the environment, then a prioritized remediation plan, then takeover of delivery until the system does what it was supposed to do. The aim is to protect the investment already made and keep what is sound rather than start again, unless the assessment shows the current design genuinely cannot be salvaged.
How does an independent assessment differ from a large integrator health check?
The scope of the inspection is similar. Global firms such as Avanade offer Dynamics 365 health check and assessment services that review configuration, customizations, security, performance, and adoption, and a good health check from any of them is worth having. The differences are independence and size. Solzet did not build the system under review and does not resell licenses, so there is no earlier decision to defend and no upsell attached to the finding. We are a small Dynamics 365 Customer Engagement and Power Platform team in Yerevan, Armenia, so the people who write the assessment are the same people who would do the remediation, and the report is written to be actionable by any partner or by your own team, including if you choose not to use us.
Can Dynamics 365 route emails automatically by topic?
Yes. In Dynamics 365 Customer Service with unified routing, inbound email is routed by topic in two stages. Work classification rules run first and stamp a topic onto the work item, either 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 Power Automate flow or plug-in has derived. The route to queues rule set then evaluates its decision list in order 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 inbound mail into cases and a record routing workstream routes those instead. Both patterns are configuration rather than custom development.
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 or cases, and it holds the work distribution mode, capacity model, and the routing configuration. A routing rule set lives inside a workstream and comes in two kinds: work classification rule sets, which run first and enrich the work item with attributes such as 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 the work waits and is assigned to an agent, with its own membership and assignment method such as highest capacity or round robin. Most broken routing we inherit fails because classification never set the attribute the decision list is testing, or because the decision list has no catch all rule at the bottom.
Will you have to rebuild everything from scratch?
Usually not. Most of what a rescue fixes is configuration of modules that Dynamics 365 already provides and untangling of customizations that should not have been written, and both are remediation rather than a rebuild. The assessment tells us what to keep, what to rework, and what, if anything, must be rebuilt, and the plan scopes the smallest rebuild that gets you to a working solution. Where the honest answer is that a component cannot be salvaged we say so plainly rather than layering more work on a broken foundation.
What do we get at the end of the assessment?
A written diagnosis and a prioritized remediation plan. The diagnosis records what is sound, what is broken, what is missing, and the root causes behind the symptoms you can see, with the evidence from the environment behind each finding. The plan sets out the fixes in order, tied to business outcomes, separating quick configuration wins from the work that needs development, and stating clearly anything that cannot be salvaged. The scope of the assessment is agreed before it starts, and the report is yours to act on with any partner or with your own team.
Can you take over while our original partner is still involved?
Yes. Some rescues are a full takeover of delivery and others are a split, where we remediate a specific area such as Customer Service routing, the Dataverse model, or the custom code while your existing partner continues elsewhere. We also work on a B2B and white-label basis for other Microsoft partners who need to rescue a project without the end client seeing a change of face. What matters is that ownership of each area is unambiguous, which is something the remediation plan states explicitly.
Which parts of Dynamics 365 do you rescue?
Dynamics 365 Customer Engagement and the Power Platform, which is what we build in every day: Sales, Customer Service including Omnichannel and unified routing, Field Service, model driven and canvas apps, Power Automate, Power Pages, Dataverse, plug-ins and custom APIs, and PowerApps Component Framework controls. We do not take on Business Central or Finance and Operations work, so if that is where your project is in trouble we will tell you at the first conversation rather than learn it on your budget.
Need an independent read on a failing implementation?
Solzet assesses and rescues stalled Dynamics 365 Customer Engagement and Power Platform projects from Yerevan, Armenia, for clients and Microsoft partners across Europe and the US. Tell us what is broken and you will get an honest diagnosis and a plan you can act on with any partner.