A customer places an order on Shopify, payment is accepted, and the order confirmation arrives immediately. But the order never reaches Sage 200 or the warehouse system. By the time someone notices, the promised dispatch date has passed, customer service is chasing answers, and the finance team has an exception to reconcile. Integration observability is the discipline of seeing that failure quickly, understanding why it happened and proving that the correct data has reached every required system.

For a retailer, wholesaler or distributor, integrations are not background IT plumbing. They control whether orders can be picked, whether stock shown online is credible, whether invoices are accurate and whether courier tracking reaches the customer. An integration that works most of the time can still create a substantial operational burden if failures are only found through complaints, missing orders or month-end reconciliation.

What is integration observability?

Integration observability is the ability to monitor and investigate the flow of data between connected business systems. It goes beyond knowing that an integration service is running. A service can be available while individual orders, stock updates or customer records fail partway through the process.

Useful observability answers practical questions such as:

• Did order 104582 leave the eCommerce platform?
• Was it accepted by the ERP system and assigned the correct customer, tax treatment and delivery method?
• Did the warehouse receive a pickable order?
• Was the dispatch confirmation returned to the sales channel?
• If a step failed, what was the error, who owns the action and has it been resolved?

This requires visibility of individual transactions as well as the overall health of the integration. It also requires enough context to investigate without asking a developer to read raw logs for every exception.

Why integration observability matters to operations

Most integration issues are not complete outages. They are partial failures: one sales channel stops sending orders, a new SKU is rejected because a required attribute is missing, a customer record cannot be matched, or a courier response is delayed. These issues are easy to miss when a team only checks whether the integration platform is online.

Consider stock synchronisation. If the ERP remains the stock authority, product availability may need to pass from the ERP to Shopify, Amazon, eBay or another sales channel. A failed update can leave an item available online after it has been allocated elsewhere. The outcome may be backorders, awkward customer conversations and additional work for warehouse and customer service teams.

The same applies to financial processes. When an order is successfully despatched but its invoice or credit note does not reach the ERP, the problem may remain hidden until finance investigates a discrepancy. Observability makes these exceptions visible when they occur, rather than allowing them to accumulate.

For managers, the value is not a screen full of technical messages. It is confidence that critical business processes have completed and that exceptions are being dealt with in a controlled way.

The difference between monitoring and observability

Monitoring usually tells you whether a system or process is available. For example, it may confirm that a scheduled task ran at 10:00 or that an API connection responded. This is useful, but it is only part of the picture.

Observability helps explain what happened within the process. If a scheduled order import ran successfully but imported 97 orders instead of the expected 103, monitoring alone may not reveal the gap. An observable integration can identify the six rejected records, show the relevant error messages and retain the source references needed to correct and reprocess them.

There is a trade-off. Capturing every field from every transaction can create unnecessary storage, security and support overhead. A sensible design records the information needed to trace, diagnose and safely retry a transaction, while protecting sensitive customer and payment data. The right level of detail depends on the process, risk and systems involved.

What good integration observability looks like

A practical approach begins with the business events that matter. For many multichannel organisations, those events include order capture, order release to the warehouse, stock adjustment, despatch, tracking update, invoicing, customer creation and product or price changes.

Each event should have a clear route and a way to be traced. In practice, that often means carrying identifiers such as an order number, ERP document number, SKU, customer account code or courier consignment number through the process. When an Operations Manager asks where an order is, the team should be able to follow it across systems without relying on timestamps and guesswork.

Statuses should reflect business reality

A status of successful is not always sufficient. An order may have been received by an integration platform but still be waiting for a customer record, stock allocation or warehouse release. Clear statuses such as received, validated, created in ERP, released for fulfilment, despatched and failed give operational users a more meaningful view.

The status model should also distinguish temporary and permanent failures. A short-lived API timeout may be appropriate to retry automatically. An invalid delivery postcode, missing product mapping or closed customer account normally needs a person to correct the underlying data before retrying. Treating both failures in the same way can either create unnecessary manual work or repeat an error until queues become congested.

Alerts need owners and priorities

An alert is useful only when the right person can act on it. A failed overnight stock update may require attention before the next trading day. A single non-critical product image failure may not. Alert rules should reflect the operational consequence, not simply the presence of a technical error.

Set escalation around agreed thresholds: perhaps a failed order that cannot be retried, a growing exception queue, no stock updates for a defined period, or courier tracking messages that have stopped arriving. Avoid alerting on every transient warning. Too much noise encourages people to ignore the notifications that matter.

Exceptions need a safe path back

Observability should not merely identify failures. It should support a controlled recovery process. This may include a queue where authorised users can see the error, correct a mapping or source record, and reprocess the transaction without creating duplicates.

Idempotency is relevant here, even if the technical term is not used day to day. Retrying an order must not create a second sales order, duplicate invoice or repeated courier booking. The integration design needs checks that recognise when the intended record already exists and determine whether the next step can proceed safely.

Building observability into an integration project

The best time to define observability is during discovery and solution design, not after a live issue exposes a gap. Start by mapping the end-to-end business process and identifying the points where incomplete or incorrect data would affect customers, fulfilment or finance.

For each flow, agree the source of truth. For example, Sage 200 may own stock and invoicing, Shopify may own web orders and customer-facing product content, while a warehouse system owns pick, pack and despatch activity. This makes it easier to decide which events should be recorded, which system should be queried first, and how conflicting updates will be handled.

Then define the operational questions the support team must answer. How long can an order wait before it needs intervention? Which fields must be present before a customer is created? What happens if a courier label is created but the tracking number cannot be returned to the storefront? Who is permitted to reprocess a failed invoice?

Testing should cover these scenarios, not only the happy path. Use representative test orders, including split deliveries, missing product mappings, amended addresses, cancelled orders and partial refunds where they apply. Confirm that errors are understandable to the people who will resolve them and that reprocessing behaves as expected.

Choosing the right level of visibility

Not every integration needs a sophisticated dashboard from day one. A lower-volume B2B order feed may be well served by a daily reconciliation and targeted failure alerts. A high-volume multichannel operation, where orders and stock move continuously, may need near-real-time exception handling and operational reporting.

The key is to match the controls to the cost of failure. If a missed order directly affects same-day despatch, it deserves rapid detection. If a periodic product attribute update fails, a scheduled review may be proportionate. The aim is not to monitor everything equally. It is to make high-impact exceptions visible before they become customer or financial problems.

At Harmonise, integration discovery and support work often starts with these operational questions rather than a generic monitoring checklist. Whether the process connects ERP, eCommerce, warehouse or courier systems, visibility should be designed around how the business actually works.

A useful next step is to take one high-volume process, such as web order to despatch, and trace how your team would investigate a missing transaction today. The places where that investigation relies on spreadsheets, inboxes or assumptions are usually the first places where better integration observability will pay its way.