Dynamics 365 Rescue Services: How to Fix a Failed or Stalled Implementation

What immediate crisis steps can you take with no budget or IT staff?

Many people reach this page in the middle of the failure rather than while choosing a partner: the project has stopped, the money has gone, and there is nobody technical left to ask. Everything in this section is free, needs only the licences you already hold, and can be done by a capable business user with administrator access in about a day. Do it in this order. It protects what you still have, it stops the situation getting worse, and it makes any later rescue markedly cheaper than one that starts from a system nobody preserved.

1. 1

   Freeze change before you do anything else

   Nothing costs less or buys more time than stopping uncontrolled change. Send one written message saying that no new configuration, no new flows, and no new deployments go into the production environment until further notice, and name the single person who can lift the freeze. Then make the freeze real: cut the System Administrator and System Customizer security roles back to the few people who genuinely need them, and stop anyone editing directly in production. If an outside partner still has access, put the freeze in writing to them too and ask for a list of everything they have in flight. A frozen system is not a fixed system, but it stops the problem growing while you work out what you are dealing with, and every step below is safer once change has stopped.

2. 2

   Take a manual backup today and find out how long your restore window really is

   Production environments are backed up by the platform automatically, but those system backups are kept only for a limited retention window, and that window is shorter than most people assume. In the Power Platform admin center, select the environment, open its backups, and create a manual backup with a note saying why you took it. Manual backups are retained longer than system ones and cost nothing beyond capacity you already hold. While you are there, read the retention period your own tenant actually shows and write down the date the oldest usable restore point expires, because that date, rather than your budget, is the real deadline on several of the decisions ahead. Do not restore anything yet. The point today is only to make sure a point to go back to still exists tomorrow.

3. 3

   Export the data the business cannot lose into files you hold yourself

   A backup inside the tenant protects you against the environment. Files you hold protect you against everything else, including losing access to the tenant. Work through the tables the business genuinely cannot lose, normally accounts, contacts, cases or opportunities, activities, and whatever custom table holds your core records, and export each one from a view using Export to Excel as a static worksheet, or from Advanced Find where the view does not carry every column you need. Date every file and store it outside the tenant. Two things are easy to miss: notes and attachments do not come out with a standard export, and neither does anything in a table nobody remembered to list, so walk the table list rather than working from memory.

4. 4

   Export the configuration as well, not just the records

   The build is worth as much as the data and is easier to lose. In the maker portal, open Solutions and export the unmanaged solutions that contain your customizations, then export a copy of any Power Automate flows that live outside a solution, because those are the ones that disappear quietly when a licence lapses or a person leaves. Save the exported files with the same date stamp as the data exports. If a previous partner holds the source code for plug-ins or custom controls, ask for it in writing now, while the relationship still functions, and check whether your contract already says it belongs to you. A rescue that starts with the configuration in hand is materially cheaper than one that starts by reconstructing it from the deployed system.

5. 5

   Turn off what is actively damaging data, and write down everything you turn off

   Damage to data is a different problem from a system that merely does not work, because it compounds daily and it is the hardest thing to undo later. Look for the things that write on their own: Power Automate flows, classic workflows, automatic record creation rules, bulk delete jobs, and any integration writing into Dataverse. Read the run history for flows failing repeatedly, and for the more dangerous case of a flow succeeding while doing the wrong thing, then switch off anything overwriting, duplicating, or deleting records. Turn off rather than delete, and keep a plain list of what you disabled, when, and why, so it can be put back deliberately instead of rediscovered. If you cannot tell whether something is damaging data, ask whether anyone would notice if it stopped for a week, and if the answer is no, turn it off.

6. 6

   Make sure your own organization holds the keys

   A surprising number of failed projects are held together by one account belonging to somebody who is about to leave. Confirm that at least two people inside your organization hold Global Administrator and Power Platform Administrator, that you know the owner and the credentials of every service account your integrations run as, and that the connections and connection references behind your flows are not all owned by one individual. Check who owns each environment, who administers the source control repository, and whether the licences on the accounts your automation runs under are current. None of this fixes anything today, and all of it decides whether a fix is still possible next month.

7. 7

   Run the business on the smallest manual workaround you can defend

   While the system is frozen people still have to work, and the real danger is that every team invents a different workaround. Pick one and mandate it. One shared mailbox or one queue, worked by a named person on a rota, rather than mail sitting in individual inboxes. One spreadsheet, in one place, with column headings copied exactly from the fields in Dynamics 365, so what is captured by hand can be loaded back later instead of retyped. One rule that every row carries a date, a person, and the record it belongs to. Tell users plainly what is frozen, what to do instead, and when they will hear next, because silence is what sends a team back to spreadsheets permanently. Then count the hours a week the workaround costs, because that number is what turns the conversation about paying for a fix from an argument into arithmetic.

8. 8

   Use the support you are already paying for

   Before spending anything, use what the licences already include. A Microsoft support request raised from the Power Platform admin center or the Microsoft 365 admin center costs nothing on a standard subscription, and it is the right route for anything that looks like a platform fault rather than a build mistake: an environment that will not restore, mailbox synchronization failing across the tenant, capacity blocking work, or a service level outage. Microsoft will not redesign your solution or repair a badly built customization, so be honest with yourself about which of the two you have before raising the ticket. Check the service health pages at the same time, because now and again the crisis turns out not to be yours at all.

What can an admin actually fix with zero budget and no consultant?

If you cannot spend anything and cannot hire a consultant, there is still real work an administrator can do with no licence purchase and no developer. Simplify forms and views for each role so people see only what they use. Switch off automation nobody depends on. Clean up data with Advanced Find, bulk edit, and duplicate detection. Capture evidence of every change in case anyone audits it. And use free tooling to inventory what the environment contains. Then be honest about the boundary: some problems cannot be fixed without a developer or a spend decision, and knowing which ones lets you build an internal case instead of grinding at something that will not yield.

Do these once the crisis steps above are done, one at a time, with a dated export before anything that changes data. Menu names move between releases, so where a screen does not match, check current Microsoft documentation for the same setting.

1. 1

   Simplify forms and views for each role

   Much of what users call a broken CRM is a screen showing everything to everyone. In the maker portal, make a copy of the main form for each role that works a table differently, remove the fields and tabs that role never uses, and assign each form to the security roles that should see it, with a sensible form order so the right one opens first. Do the same with views: one short system view per role with the columns that role actually filters on, set as the default where it helps. Where people move between several unrelated areas, a model-driven app per role that only contains the tables that role needs is also configuration, not code. Hide rather than delete fields until you are sure nothing reads them.

2. 2

   Switch off automation that is not essential

   Separate from the damaging automation already turned off in the crisis steps, most tired environments carry automation that simply adds noise and slowness: classic workflows nobody remembers, flows sending notification emails people filter to a folder, business rules duplicating each other, and duplicate detection jobs or scheduled processes running against tables nobody uses. List them, ask each business owner whether anything depends on them, and turn off, rather than delete, what nobody claims. Keep the list of what you turned off and when. Fewer moving parts makes every later diagnosis quicker, whoever does it.

3. 3

   Clean up data with Advanced Find, bulk edit and duplicate detection

   Use Advanced Find, or the modern advanced find and view filters in newer interfaces, to build a view of one specific problem at a time: accounts with no owner, open opportunities with a close date years in the past, contacts with no email and no activity, cases still open for customers who left. Correct them from the grid with bulk edit a page at a time, or export to Excel, correct, and import back where the change is larger. Run duplicate detection jobs and merge obvious duplicates by hand. Deactivate stale records rather than deleting them, and take a dated export before every bulk change so it can be reversed. Bulk delete jobs remove data permanently, so leave them until you are certain.

4. 4

   Capture evidence as you go, in case anyone audits this later

   Every change above is a change to a business system, so record it. Keep one dated log of what was changed, by whom, why, and how to undo it, with the export taken before each bulk edit. Check whether auditing is enabled on the tables you are cleaning, because auditing is not retroactive and the history you will want next month only exists if it is on today. Screenshots of settings before you change them take seconds and settle arguments later. This log is also the start of the internal case for budget, because it shows what has been done without spending anything.

5. 5

   Inventory the environment with free tooling

   You cannot prioritize what you have not listed. The Power Platform admin center shows environments, capacity, and usage; the maker portal lists solutions, tables, flows and apps; and the solution checker in the maker portal runs static analysis on a solution at no cost. Where your organization permits community tools, XrmToolBox is a widely used free desktop tool whose plugins can list metadata, plug-in steps, workflows, security roles and unused fields in far less time than clicking through screens. For Power Platform estates the Microsoft CoE Starter Kit inventories apps, flows and makers. Check your internal policy before installing any third-party tool against production.

Where do it yourself stops and a rescue becomes unavoidable

The eight crisis steps and the admin fixes above are the whole of what can be done safely without help. They hold the system still and remove the friction; they do not repair the build. These are the five points where continuing alone costs more than it saves, and each one is a condition you can check for yourself rather than a judgment somebody has to sell you.

Which problems cannot be fixed without a developer or a spend decision, and why?

The conditions above tell you when to stop. These are the types of problem that no amount of careful administration will resolve, with the reason, so the time goes into the case for budget rather than into another weekend in the admin center.

How do you build a one-page cost-of-inaction calculation that unfreezes budget?

Budget rarely moves because a system is described as broken. It moves when someone can see what the current state costs per week and what it puts at risk. The page below is a method, not a benchmark: every figure in it is one you measure yourself, with its source written next to it. There are deliberately no example numbers here, because the only figures that persuade your budget holder are your own.

Put the quarterly total, its three lines of arithmetic, the list of audit gaps, and the smallest step you are asking for on one page. How to present it, who to take it to, and why three priced options work better than one request are set out in the funding case on our Dynamics 365 project rescue and takeover service page, alongside a fuller table of business risks to measure.

When one of those applies, the cheapest professional step is deliberately not a programme. Where nothing is being actively damaged and what you mainly need is to know what you are dealing with, a bounded Dynamics 365 health check and technical audit produces a written diagnosis and a prioritized plan that is yours to act on with any partner or with your own team. Where work is being disrupted right now, data is being damaged, or an outgoing partner is about to hand over the keys, our project rescue and takeover service starts with an environment lockdown and emergency triage in the first days instead of a discovery phase. And where you already know what has to be fixed and simply need senior hands to do it, hiring a Dynamics 365 developer directly is usually the smaller commitment of the three. If none of them are affordable this quarter, the steps above are still worth doing in full, and our guide to hiring a consultant against building it yourself names the points where configuration runs out.

How do you run emergency triage for broken automations and data corruption?

One failure on this page deserves its own procedure, because it is the one where the cost is financial, it compounds silently, and somebody outside the business eventually asks to see the paperwork: an SLA, entitlement, or billing automation that has started writing wrong values. A flow that fails loudly gets noticed. A flow that succeeds while doing the wrong thing marks cases as breached that were never breached, misses the ones that were, and quietly writes those figures into what customers are billed and credited, for weeks, with nothing in any alert to say so.

The order below is deliberate and it is not the order instinct suggests. Evidence comes before repair, because on this failure mode the evidence expires by itself: cloud flow run history is retained for weeks, and Dataverse audit data exists only if auditing was switched on before the failure and only as far back as your retention setting allows. Correcting records first feels productive and destroys both.

1. 1

   Establish the failure window before you touch a single record

   Every decision below depends on two timestamps: when the automation started writing wrong values and when it stopped. Take them from the process itself rather than from when somebody noticed, because the two are rarely close. For a cloud flow, open the run history and find the earliest run whose output is wrong, which is often weeks before the first complaint, since a flow that succeeds while doing the wrong thing raises no alert at all. For a plug-in, use the plug-in trace log together with the modified on dates of the records it touches. Write both timestamps in one place and treat everything inside that window as suspect until it is proved otherwise. Teams that skip this correct records at random and can never afterwards tell finance how many were affected, which is the question they will be asked first.

2. 2

   Save the flow run history now, because it expires on its own

   Cloud flow run history is retained for a limited period, commonly around four weeks, and it is removed on a rolling basis whether or not anyone is in the middle of an investigation. Before anything else, open each suspect flow, filter the run history to the failure window, and capture the trigger inputs, the inputs and outputs of the action that writes to Dataverse, and the run identifiers. Screenshots are acceptable evidence, an export is better. Do not use Resubmit while you are still investigating, because resubmitting replays the original trigger payload against current data and writes again. If several processes run on the same table, capture all of them, because a wrong value is often the result of two writers acting in an order nobody controls rather than of one broken flow.

3. 3

   Use Audit History to prove which process wrote the value

   Open one of the damaged records and look at its Audit History under the related records. Dataverse auditing records each change with the date, the user context the change ran under, the column, the old value, and the new value, and it is the only place that reliably separates an automation write from a person. A change stamped with a service account or with the identity that owns the flow connection is the automation. A change stamped with a named user is not, and that distinction decides whether you are dealing with a build defect or a process problem. Two cautions apply. Auditing is enabled at the organization, table, and column level, and it is not retroactive, so if it was off during the failure the history you want does not exist and the run history becomes your primary evidence. Retention is set at the organization level, so check how far back your own audit data actually reaches before planning around it. If auditing is off, switch it on for the affected tables and columns today, because you are very unlikely to be at the end of this.

4. 4

   Pause the faulty process rather than deleting or repairing it

   Turn the process off, do not delete it, and do not start editing it into a correct version. A deleted flow takes its run history with it, and an edited flow destroys the exact version that caused the damage, which is the version an auditor will ask to see. Turn off cloud flows, deactivate classic workflows and automatic record creation rules, deactivate the SLA rather than editing its KPIs, and disable the plug-in step rather than unregistering the assembly. Then check the three things people miss. Runs already in flight can complete after the trigger is switched off, so read the run history again a few minutes later instead of assuming the last write is already in. Deactivating an SLA stops it applying to new records and does not correct the instances it has already created. And a scheduled job or an integration outside the platform may be writing the same column, in which case turning off the flow changes nothing at all. Keep a plain log of what was paused, when, by whom, and why. That log is both your route back and one of the documents in the evidence checklist below.

5. 5

   Give finance a manual breach flag on the record itself

   Pausing the automation stops the damage and also stops the business producing the numbers it bills on, so the manual replacement has to go in the same day. Add new columns to whatever record the money is calculated from, normally the case or the agreement: a choice column for the manual determination with options such as not reviewed, breach confirmed, no breach, and cannot determine, a date for when the determination was made, a lookup to the person who made it, and a short text column for what they based it on. Never reuse the columns the broken automation was writing. Those columns are evidence, and overwriting them by hand destroys the ability to show later what the system did as against what a human decided. Then build one view filtered to the failure window and sorted by value at risk, hand it to a named person, and have them work it as a queue. Finance bills from a column that carries an owner, a date, and a reason on every row, which is a position that survives being questioned, rather than from a spreadsheet that cannot be joined back to the records it describes.

6. 6

   Quarantine the affected records instead of correcting them as they surface

   The instinct in the first hours is to fix wrong values one at a time as people report them. Resist it. Add a simple flag column, mark every record inside the failure window as suspect, populate it in bulk from the window established in the first step, and leave the values themselves alone until the whole population is known. Correcting records while the count is still moving means nobody can ever state how many were affected, the same rows get corrected twice, and the before and after evidence is lost row by row as it is overwritten. Bulk correction, when it comes, is a planned pass rehearsed in a sandbox copied from production, with counts taken before and after and with automation and duplicate detection disabled for the duration and re-enabled from a written list. The quarantine flag is what makes that pass possible, and in the meantime it tells everyone who opens one of these records that its numbers are not to be trusted.

7. 7

   Reconcile against a source the automation never touched

   The last triage step is arithmetic, and it is the one that ends the argument. Take the quarantined population and reconcile it against something the broken process never wrote to: the raw messages or events the automation read from, the timestamps on the underlying activities, the dated exports you took, or the ledger on the other side of the integration. Produce three numbers and hold them: how many records fall inside the failure window, how many carry an incorrect value, and what the money difference between the two positions is. Those three numbers are what let you tell a customer, a regulator, or an auditor what happened without hedging, and they are also what decides how much remediation is worth buying. Until they exist, every conversation about the failure is opinion, including yours.

Evidence checklist for auditors

When an automation has affected what customers were billed, the incident does not end when the flow is fixed. It ends months later, when a customer disputes an invoice, an internal audit picks the period, or an external auditor asks how the figures were arrived at while the system was known to be wrong. Almost everything on this list has to be produced during the triage above, because by the time it is asked for the run history has rolled off, the flow has been repaired, and nobody can remember what was switched off on the second day.

• The failure window, as two timestamps with a source for each

  The moment the automation began writing wrong values and the moment it stopped, each traced to the run history, the trace log, or the modified on dates rather than to when a person raised it. Everything else in the pack is scoped by these two numbers, so they are stated once and used consistently.

• Exported flow run history covering the window

  Trigger inputs, the inputs and outputs of the writing action, and the run identifiers for every suspect process. Captured during triage, because this data is retained for weeks rather than years and cannot be recovered once it has rolled off.

• Audit History extracts for a representative sample of affected records

  For each sampled record, the old value, the new value, the column, the timestamp, and the user context that made the change, which is what demonstrates that an automation and not a person produced the figure. Note in the pack whether auditing was enabled at the time, because silence on that point reads badly later.

• The pause log

  A dated list of every flow, workflow, automatic record creation rule, SLA, plug-in step, and integration that was disabled, who disabled it, and the reason. This shows the failure was contained deliberately, and it is also the list used to bring each item back.

• The faulty process preserved as it was

  An exported copy of the flow, solution, or code as it stood at the time of the failure, taken before anyone corrects it. A repaired process is not evidence of what the broken one did, and the version history is normally the first thing requested.

• The manual breach register

  The export of the manual determination columns: every record, the determination, the date, the person who made it, and what they based it on. This is what allows an invoice or a credit raised during the outage to be defended line by line.

• The affected population and its reconciliation

  The full list of quarantined records with the three counts against it: records in the window, records written incorrectly, and the value of the difference, together with the independent source they were reconciled against.

• The correction record

  What was changed back, when, by whom, under what approval, and the counts taken before and after each pass. A correction with no counts around it is indistinguishable from a second round of damage.

• The communication trail and a one page statement of facts

  Who was told what and when, covering customers, finance, and any regulator, plus a single page that states the sequence of events, the numbers, and what was done about it, with a named owner and a date. Producing this page at the end of triage rather than at the start of an audit is the difference between an incident and a finding.

Triage stops the bleeding and preserves the record. It does not tell you why a process that was signed off ever behaved this way, and on almost every engagement of this kind the broken automation turns out to be a symptom of one of the three root causes below rather than an isolated defect. To find out which, and to see what else is sitting in the same state, the same inspection run on its own is our Dynamics 365 health check and technical audit, which reads the solution layers, the run history, and the code behind the behaviour and returns a written diagnosis. Where records are being damaged right now and you need somebody to take control rather than to advise, our project rescue and takeover service begins with an environment lockdown and emergency triage in the first days, and it covers the part deliberately left out of the steps above: how a bulk correction of damaged records is sequenced, rehearsed, and proved against counts before it touches production.