Diagnosing Intermittent Dynamics 365 Failures Nobody Can Reproduce

Why do Dynamics 365 errors disappear when you try to reproduce them?

Because the person reproducing them is one user, saving one record, on a quiet sandbox. The failures that matter in production depend on things a single manual test never recreates: two processes touching the same record within the same second, an integration sending a partial update rather than the full form, an asynchronous job running minutes later than usual because the queue is busy, or a bulk update pushing a plug-in loop past its time limit.

That is why these problems survive for months. Each report arrives as "it failed for someone this morning", someone tries it, it works, and the ticket is closed as user error. The general design mistakes behind many of these faults, such as slow synchronous plug-ins and logic scattered across flows and plug-ins, are catalogued on our Dynamics 365 customisation mistakes page. This page is the diagnostic method for when one of them is already hurting you.

What evidence should you capture before anyone forms a theory?

Evidence discipline is the whole difference between a fix and another month of guessing. Agree one rule with the business: every failure report must come with the time, the record, the user and the error details, and nobody changes configuration until that evidence is pulled. Then work through the sources below for the same operation.

How do you use the correlation ID to follow one failing operation?

Every plug-in execution context carries a correlation ID, and it is shared by the operations that one original request sets off, including the plug-ins it triggers and the asynchronous jobs queued from it. That makes it the thread you pull. Find the trace log row for the exception, copy its correlation ID, then filter the trace log and System Jobs by that ID. What comes back is the chain of work caused by one save, rather than everything that happened in that minute.

• Sort the trace rows by execution start time and read the depth column. Depth 1 is the original request; higher depths are operations caused by other plug-ins or workflows, which is where loops and unexpected cascades appear.
• Compare the mode column: synchronous rows ran inside the save, asynchronous rows ran later from the queue, possibly after other work changed the record.
• Check the duration column for any plug-in close to two minutes. That is the sandbox limit, and a step that takes most of it on a quiet day will exceed it under load.
• Look for two correlation IDs touching the same record within seconds. Two independent operations on one record is the signature of a race.
• Keep the IDs in the ticket. Once a fix ships, the same query shows whether the pattern has stopped.

Is the plug-in trace log switched on, and how long does it keep evidence?

Often not, which is why the first occurrence is lost. The setting lives in the system settings of the environment as "Enable logging to plug-in trace log", with three values: Off, Exception and All. Exception writes a row only when a plug-in throws, which is the sensible production default. All writes a row for every execution and is useful for a short, planned diagnostic window, but it adds load and volume and should be switched back afterwards.

Trace log rows are cleared automatically by a system bulk deletion job, by default after about a day, so they are not an archive. When a significant failure happens, export the relevant rows the same day and attach them to the incident. A trace row is also only as useful as what the plug-in wrote into it: plug-ins that call the tracing service with the record ID, the branch taken and the values read make the next occurrence readable, while plug-ins that only throw a generic message leave you with a stack trace and nothing else.

What causes Dynamics 365 plug-ins to fail only under load?

Almost every intermittent plug-in fault falls into one of a small number of patterns. Each has a recognisable trace, so match the evidence to the pattern rather than starting from the code.

Why do plug-ins fire in the wrong order and corrupt data?

Usually because nobody decided the order. Each registered step has a stage, a mode and an execution order, and together they are the only contract you have. Pre-validation runs before the main system operation and, for the original request, outside the database transaction. Pre-operation runs inside the transaction before the record is written, which is where you change values on the Target. Post-operation runs after the write; asynchronous steps can only be registered here, and they run later from the queue in their own transaction.

Within one message and stage, steps run in ascending execution order. When two steps share the same value, their relative order is not guaranteed, and real-time workflows on the same message add more writers whose timing relative to your plug-ins you should not rely on. The corruption appears when one step reads a value another step was supposed to set first, or when an asynchronous step overwrites a value a later synchronous save already corrected.

• List every step, real-time workflow and automated cloud flow on the affected table and message, with stage, mode, execution order and filtering attributes, in one table.
• Give every step an explicit, distinct execution order and write down why it runs where it does.
• Set values in pre-operation on the Target instead of issuing a separate update in post-operation, which triggers the pipeline again.
• Keep one owner per column: if a plug-in and a flow both set the same column, decide which one owns it and remove the other.
• Narrow filtering attributes so update steps only fire when the columns they care about change.

How do you handle the two-minute plug-in timeout on bulk updates?

Plug-ins run in the sandbox with a two-minute execution limit, and it applies whether the step is synchronous or asynchronous. You cannot raise it. A plug-in that updates every related record in a loop, or waits on an external service, will pass every test with ten children and fail on the account with thousands, or when a bulk update from an integration arrives while the system is busy.

The fix is to stop doing unbounded work inside one plug-in execution. Keep the synchronous step to validation and the values that must be correct at save time, and hand the rest to a process built for volume.

• Move fan-out work, such as updating every child record, out of the plug-in and into a queued process: an Azure Service Bus queue fed by a service endpoint and processed by Azure Functions, or a Power Automate flow that pages through records in chunks.
• Process in bounded batches, each well inside the limit, and record progress so a failed batch can resume rather than start again.
• For integrations and data fixes that send many requests, group them with ExecuteMultiple or the CreateMultiple and UpdateMultiple messages, and respect service protection limits by backing off when the service asks you to. Throughput for large loads is covered in our Dataverse bulk import guide.
• Remember that each record in a bulk operation still runs its plug-ins, so a slow step is multiplied by every row. Make the step fast before making the batch bigger.
• Never call slow external services synchronously from a plug-in. Queue the call and write the result back.

How do you reproduce an intermittent failure deliberately?

Recreate the conditions, not the click. Use a sandbox copied from production so the data volumes, related record counts and registered steps match, and switch the trace log to All for the duration of the test only.

• Replay the real payload: send the same partial update the integration sends, not a form save with every column.
• Add concurrency: run the same operation against the same record from several parallel clients at once, using a small load harness or test tool that calls the Web API.
• Add delay: pause or slow the asynchronous job the failing step depends on, so the dependent record does not exist yet when the synchronous step runs.
• Add volume: run the bulk update against a record with the realistic maximum number of children, and watch plug-in durations approach the two-minute limit.
• Keep a written script of each run with its correlation IDs, so a reproduction becomes a regression test once the fix is in.

What should you do first if data is being corrupted right now?

Contain before you fix, and do not destroy the evidence you need for both the fix and the data repair. Work in this order, logging each change with its time.

How do you fix these faults so they stay fixed?

Most permanent fixes are small and structural rather than clever. The aim is that the design no longer depends on timing.

• Explicit stage and execution order on every step, documented next to the code, with no two steps on one message and stage sharing a value.
• Guarded retrieves: check that a related record or lookup exists before using it, and when it legitimately may not exist yet, defer the work to an asynchronous step or a retry rather than throwing.
• Pre-images and post-images registered for every column a step reads, so partial updates do not produce nulls.
• Stateless plug-in classes: no instance or static fields holding per-execution data.
• Depth checks where a step can trigger itself, and filtering attributes on every update step.
• Consolidated overlapping logic: one plug-in or one flow owning a column, instead of a plug-in, a real-time workflow and a flow each doing part of it.
• Asynchronous chunking for any work that grows with data volume.
• Tracing in every plug-in that writes the record ID and the decision taken, with the trace log left on Exception in production, and telemetry sent to Application Insights where your environment supports it.

When is the problem the platform choice rather than the plug-ins?

Rarely, for this class of fault. Races, timeouts and ordering faults come from design, and they appear on any platform with triggers, background jobs and concurrent writers. Moving to another system without fixing the design moves the problem with it. If the investigation shows the environment has much wider issues, an independent Dynamics 365 health check and technical audit gives you the full picture and the evidence for it before any decision to rebuild.

We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both. Where the evidence points to a process Dynamics 365 licensing and its customisation model do not suit, a custom-built CRM on React, Node.js, PostgreSQL or .NET is the alternative, designed with its own queues and transactions from the start.

How does Solzet diagnose and fix intermittent Dynamics 365 failures?

We work in the order of this page. First the evidence: trace logging, correlation IDs, System Jobs and audit history for real failures, pulled before anyone changes a thing. If data is being damaged, containment alongside your team, with each change logged and reversible. Then a map of every step, workflow and flow on the affected tables, a deliberate reproduction under concurrent load in a sandbox, the fix shipped through managed solutions, and the data repair.

We leave behind tracing in the code, a documented step register and the reproduction scripts as regression tests. Solzet delivers remotely from Yerevan, Armenia, with senior consultants and full-stack developers and 8+ years of Dynamics 365 Customer Engagement and Power Platform work, directly or white-label for Microsoft partners. The plug-in and Dataverse development side is described on our Dynamics 365 development service.