Your systems are connected. Who notices when data stops moving?

Sales can see the order in the CRM. Operations cannot find it in the ERP. Finance is working from yesterday’s figures. Everyone has been told that the systems are connected, yet someone still spends the morning checking what arrived.

For a growing business, integration needs to answer a simple question: did the right information reach the right place, in time for someone to use it?

A connection can be available while an individual record is missing, delayed or wrong. The useful outcome is a dependable business process, with a clear response when something goes wrong.

Start with the handoff that matters

Choose one connection whose failure would disrupt a real activity. That might be approved orders moving into the ERP, invoices reaching the finance system, or stock updates reaching the online shop.

Write down what should move, when it should arrive and what the receiving team needs to do with it. Include the conditions that make a record eligible: an approved order and a draft order should not necessarily follow the same route.

Agree the acceptable delay around the business need. An overnight reporting feed and an order needed for a same-day despatch have different consequences. There is no universal threshold that makes every integration healthy.

Check business completion

Ask for two views of the handoff. The technical view shows whether the connection ran and reported errors. The business view shows whether the expected records arrived and remained usable.

For example, in an illustrative distributor, the morning check could compare eligible orders in the CRM with orders accepted by the ERP. It should identify missing references, rejected records and unexpected duplicates, using the same period and agreed rules.

Matching counts alone would not prove that the right orders arrived. A missing order and a duplicate could cancel each other out. Check record references and important fields such as customer, quantity and delivery date where they matter.

Also distinguish an unusually quiet day from a stalled feed. Compare activity with its source rather than assuming that zero records always means failure.

Make exceptions somebody’s responsibility

A useful exception tells a person what needs attention. “Integration error” gives operations very little to work with. “Approved order not received by the agreed despatch check” points towards a business consequence.

Assign a process owner and a technical owner. The first decides what the business should do; the second investigates and repairs the connection. Agree cover for absence, who receives unresolved issues and how the two owners communicate.

Keep an accessible exception queue with the record reference, age, reason and current owner. Provide enough context to investigate without copying unnecessary customer details or confidential data into email alerts.

Microsoft’s Power Automate guidance describes error-handling paths, logging and notifications, including actions that follow a failure or timeout.^[1] These are implementation tools. The business still needs to decide who acts on a notification and what completion means.

Recover without creating more work

Before asking someone to rerun a failed transfer, establish what already happened at the destination. A delayed response does not necessarily mean that nothing was written.

Ask the delivery team how the solution recognises a record it has already processed. Repeating a transfer should not create a second invoice, order or stock movement. Microsoft’s architecture guidance highlights repeat-safe processing when a message may be processed more than once.^[2]

Temporary interruptions and invalid business data need different responses. A short service interruption may justify a controlled retry. An unknown product code may need correction by a data owner. Repeating the same invalid record indefinitely would leave the underlying problem unresolved.

Agree a bounded recovery process, keep a record of the decision and check the result afterwards. If people must use a temporary manual workaround, document how those records will be reconciled when the connection resumes.

Test the awkward cases

Include more than a successful demonstration. Ask the team to show what happens when a destination is unavailable, a required field is missing, a record arrives twice, or information is updated after its first transfer.

Use an authorised test environment or controlled test records wherever possible. Avoid disrupting live customers to prove that an alert works.

For each test, check detection, ownership, recovery and the final business record. Confirm that the warning reaches the right person and that a resolved issue leaves the exception queue. Alert noise makes it harder to notice the issue that matters.

Make this a manageable first improvement

You do not need to replace every integration to begin. Select one important handoff and put its expected outcome, checks, owners and recovery steps on a single page.

Track unresolved exceptions, their age and repeated causes. Use that evidence to decide whether the next improvement is a data correction, a process change or an engineering fix.

The question for a supplier becomes more useful too: “How will we know this process completed, and how will we recover if it did not?” That is a stronger acceptance criterion than simply confirming that two systems can connect.

Discuss your integration challenge

If teams still chase missing records between connected systems, discuss your automation and integration challenge with Qubit. Start with the handoff, the operational impact and the outcome you need.