Dynamics 365 Integration and Omnichannel Breakdowns: Emergency Triage Before You Rebuild

What does an integration that silently loses records look like?

Nobody reports "the integration is losing records". They report a business symptom, usually days after the loss began, and usually to someone who does not own the integration. The first job is to translate the symptom into the boundary where data should have crossed and did not. The table maps the complaints we hear most often to the place worth looking first.

In what order should you diagnose the channel, the routing, the connector and the downstream system?

Work from the point where the customer or the business event entered, towards the system that should have received it, and stop at the first layer where the record is missing. Checking the downstream system first is tempting, because that is where the complaint lands, but it tells you only that the record is not there, not where it was lost.

Are dropped chats the same problem as lost integration records?

No, and treating them as one problem slows both fixes down. Chats that disconnect, time out or vanish from an agent session are an Omnichannel identity, routing or network issue, and we have a separate, step by step guide for that: how to fix Dynamics 365 Omnichannel agent disconnections and chat timeouts. The only overlap is when a chat or case creates a record that is then meant to flow into another system. Once the conversation record exists in Dataverse, the rest of this page applies.

How do you detect missing records before a customer does?

Error alerts alone cannot catch silent loss, because silent loss is by definition the case where nothing errored. Two controls catch it: reconciliation and alerting on silence.

• Count by business key per day on both sides. For each integrated entity, count the records created or changed per day in Dynamics 365 and the matching records received in the target, keyed by the identifier both systems share: order number, invoice number, work order number. Compare the keys, not only the totals, because one duplicate and one loss cancel each other out in a total.
• Add a value check for anything financial. Alongside the count, compare the sum of amounts per day. A count that matches with a sum that does not points at a mapping or rounding fault rather than a lost record.
• Alert on silence, not only on error. If an order flow normally runs dozens of times a working day, zero successful runs in a working morning is an incident, even though nothing has failed. A scheduled check that counts recent successful runs or recently synced rows, and alerts when the number falls to zero, catches expired secrets, turned-off flows and stalled queues that raise no error at all.
• Run the monitor under a different identity from the integration. A check that authenticates with the same expired secret goes quiet at the same moment as the thing it watches.
• Watch the age of records in intermediate states. Items sitting in "sent to ERP" or "awaiting confirmation" longer than the normal cycle are the earliest sign that responses are no longer coming back.
• Send the alert to a named owner and a shared channel, not to the mailbox of whoever built the flow. Power Automate failure notices go to the flow owner, who may have left.

How do you prove where a record was lost?

Before anyone changes anything, capture evidence at the boundary for one specific missing record. A single traced record settles arguments between the CRM team and the ERP team faster than any meeting. Several of these artefacts are retained only for a limited time, so capture them the day you find the loss.

What actually causes an integration to lose records?

Once one missing record is traced, the cause almost always falls into one of five families. Classifying it matters because each family has a different containment and a different permanent fix.

How do you contain the damage within a day without rebuilding?

Containment has one aim: stop customer-visible damage today while preserving everything you need to repair the data tomorrow. The general freeze discipline, turning processes off rather than deleting them, and the three reconciliation numbers are set out in our Dynamics 365 rescue services guide. For an integration specifically, the day looks like this.

• Stop the writer that is doing damage, not the capture. If the outbound side is writing wrong data into the ERP, turn off that flow or disable that plug-in step, but leave the source records and any queue intact so messages accumulate rather than disappear.
• Turn on payload capture and plug-in tracing for the affected path before you touch the fix, so the next failure is recorded in full.
• Build the gap list. Using the daily key reconciliation, list every business key present on one side and missing on the other for the whole failure window, not only the records customers have complained about.
• Fix the narrow cause. A renewed secret, a corrected mapping value, a retry policy or a restored connection owner is usually a same-day change, promoted through your normal path rather than typed into production.
• Replay by key, not by date range. Resend only the listed keys, through an idempotent upsert, so a replay cannot create the duplicates that a second run of a date range would.
• Protect the customer-facing process while you replay: a manual check on dispatches or shipments for the affected keys, and a named person who confirms each one has landed.
• Put the silence alert in place before you close the incident, so the same failure cannot run unnoticed a second time.

When does a broken integration genuinely justify a rebuild?

Most silent loss is fixed without a rebuild: an expired secret, a missing retry, a mapping gap. Rebuilding because an integration embarrassed everyone once is expensive and often reintroduces the same faults. A re-architecture is justified when the design itself prevents the controls above from working.

• Writes cannot be made idempotent, because there is no shared business key or alternate key, so every replay risks duplicates.
• Nothing can be replayed: messages are sent once, with no queue, no stored payload and no way to resend a single record.
• Changes are detected by polling for rows modified since the last run, and records are lost whenever a run fails, overlaps or the clock drifts.
• The logic is spread across flows, classic workflows, plug-ins and scripts that nobody can read, so a fix in one place breaks another.
• The volume has outgrown the pattern, and the integration now lives permanently at the service protection limits.
• The same five causes keep recurring after each fix, which means the containment has become the operating model.
• If a rebuild is justified, the CRM side of it is also the moment to check the platform still fits. 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. For some organizations the honest answer is a custom CRM built without Microsoft licensing, integrated directly with the ERP they already run.

What does Solzet fix, and what stays with your ERP or SAP team?

Solzet fixes the CRM side and the integration between the systems: Dynamics 365 Customer Engagement and Dataverse, plug-ins, Power Automate cloud flows and desktop flows, service endpoints and the queues, retry, logging, reconciliation and alerting around them. We do not configure, implement or repair the ERP or SAP system itself, and we do not deliver Dynamics 365 Finance, Business Central, Finance and Operations or other ERP implementations. We treat ERP endpoints as external systems: we trace the message to their boundary, show your ERP team or partner exactly what was sent and what came back, and work alongside them while they fix their side.

That split is usually what ends the loop where each team is certain the fault is on the other side, because the traced record shows plainly where it stopped.

When should you bring in a rescue partner instead of patching it yourself?

Patch it yourself when one cause is traced, the fix is narrow and the replay list is complete. Bring in help when records are being damaged rather than only missed, when nobody left can read the code the integration depends on, when the same failure has returned after two fixes, or when the original partner has stopped answering. Our Dynamics 365 project rescue and takeover service covers the emergency first days, including the identities your integrations run as, and a Dynamics 365 health check and technical audit runs the same inspection outside a crisis. Solzet brings senior consultants and full-stack developers with 8+ years of Dynamics 365 and Power Platform delivery, working from Yerevan in GMT+4.