Plan reliable business integrations with stable identifiers, safe retries, visible exceptions and reconciliation for delayed or duplicate orders.
A customer order leaves one application, but the receiving system takes too long to respond. The sending application tries again. Did the first attempt fail, or did it succeed without returning confirmation? If the integration treats those possibilities as identical, the business may receive two orders for one request.
Delayed updates create a different problem. Sales sees an order as approved while dispatch still sees it as pending. Staff telephone each other, create a manual copy or change the status twice. By the time the connection catches up, the records no longer tell a consistent story.
Reliable integrations require more than moving fields between applications. They need rules for identity, ownership, retries, timing and exception handling. Those rules should be understandable to the people responsible for sales, stock and finance, even when developers implement the technical details.
Begin with the business event
Define exactly what the integration represents. “Send an order” could mean sharing a draft, requesting approval, confirming a commercial commitment or instructing dispatch. These events have different consequences and should not be merged into one ambiguous action.
Write the event in business language, including its prerequisites. An approved-order event might require a valid customer account, agreed items and quantities, an authorised approver and a delivery reference. The receiving system should know what it can safely assume when that event arrives.
Identify the irreversible or difficult-to-reverse consequences. Creating a draft record is different from releasing goods or recording a financial posting. The more consequential the action, the more carefully the integration must distinguish a new instruction from a repeated delivery of an existing instruction.
For Pakistani businesses connecting branch, warehouse and head-office applications, this definition helps separate communication delays from genuine business decisions. A slow connection should not silently turn one approved request into multiple commitments.
Give records stable identifiers
Every transaction needs an identifier that survives movement between systems. A display number may be suitable if its uniqueness and stability are guaranteed within the required scope. Otherwise, maintain a dedicated integration identifier and preserve the relationship to the user-facing references.
Avoid matching orders solely by customer name, amount or timestamp. Two valid orders may share those values, and a corrected address should not cause a record to appear new. Define which system issues the identifier and how branch or company boundaries affect uniqueness.
Retain mappings between source and destination identifiers. Support staff should be able to trace a source order to its receiving record without searching manually through descriptions. This mapping also supports reconciliation and controlled repair when an integration pauses or resumes.
Make repeated delivery safe
An integration often needs to retry after temporary failures. Safe retry behaviour means that the receiving side can recognise a repeated request and avoid applying the same business effect again. Developers commonly describe this property as idempotency, but the practical question is simple: what happens if the same instruction arrives twice?
Agree the identifier used to recognise repetition and how long that protection must remain effective. The design should account for delayed retries and recovery after an interruption. A short-lived memory of recent requests may be insufficient if staff can replay older transactions later.
Also define what happens when the same identifier arrives with different content. Silently accepting the newer payload can conceal an error; treating it as a completely new order can duplicate the commitment. The correct response depends on the workflow, but it should be explicit, traceable and testable.
Do not promise universal “exactly once” behaviour based only on a successful demonstration. Evaluate the complete path, including receiving actions, acknowledgements and recovery. The business needs evidence that repeated delivery does not cause unintended repeated effects under the tested conditions.
Separate temporary failures from invalid requests
A temporary connection problem may justify another attempt. A missing customer identifier or invalid item code usually requires correction. Repeating an invalid request continuously consumes capacity and hides the underlying issue without moving the transaction forward.
Classify failures into useful operational categories. For each category, define whether the integration retries automatically, waits for a dependency, stops for review or rejects the request. Record enough context for the responsible person to act without exposing unnecessary sensitive data in logs.
Set retry limits and spacing deliberately. An immediate flood of retries can make an overloaded receiving service less responsive. A long delay may be inappropriate for a time-sensitive workflow. The schedule should reflect the business requirement and supported technical behaviour, with an escalation when the agreed waiting period is exceeded.
Maxicon’s IT consultancy service offers a relevant starting point for mapping these business rules before an integration is commissioned or revised.
Make pending work visible to users
A transaction that is awaiting delivery should not look identical to one that has been accepted. Use clear statuses such as prepared, awaiting transfer, received, rejected and requiring review, adapted to the actual workflow. Explain what each status permits staff to do.
Distinguish technical receipt from business acceptance. A receiving service may acknowledge a message before validating its contents or creating the final record. Staff should not assume that a technical acknowledgement means stock has been reserved or an invoice has been posted.
Show the last successful update and relevant exception information where users make decisions. If stock availability is delayed, label the information accordingly. This gives staff a reason to follow the approved exception process instead of inventing a second transaction to force progress.
Protect the order of changes
Updates can arrive out of sequence. An order amendment may reach the destination before the original order, or an older status may arrive after a newer one. Without a rule for ordering, a late message can overwrite a valid current state.
Define which changes are allowed from each business status. A cancelled order should not become approved merely because an earlier approval message arrives late. Use version or sequence information where the implementation supports it, and specify how missing predecessors are handled.
Consider which fields can be merged independently and which form one controlled transaction. Updating a contact note is different from changing an approved quantity. If multiple systems can alter the same business fact, resolve ownership before implementing conflict rules. Otherwise, the integration becomes an automated argument between competing sources.
Build an exception queue people can operate
An exception queue is useful only when someone owns it. Assign responsibility by business issue: an unknown item may belong to operations, a blocked customer to finance and a connection failure to IT. Provide a route for issues that cross those boundaries.
Each exception should show the affected record, reason, age, current owner and permitted next actions. Include a link to the underlying business record where practical. Avoid requiring business users to interpret raw technical messages that do not explain what needs correction.
Control replay actions. After fixing a missing reference, a user may need to resubmit the original instruction. The replay should retain the appropriate identity and audit trail. Creating a fresh transaction to bypass an exception can defeat duplicate protection and make reconciliation harder.
Reconcile independently of error alerts
An integration can lose or misroute work without producing an obvious error for a user. Reconciliation compares expected business records with the results in the receiving system. It provides a separate way to detect missing, duplicated or inconsistent transactions.
Choose comparisons that reflect the process. Review identifiers, counts, statuses, quantities and relevant totals within an agreed period. Counts alone are insufficient: one missing order and one duplicate order can leave the count unchanged. Include record-level matching for important transactions.
Define how differences are investigated and closed. A reconciliation report that grows indefinitely becomes another ignored queue. Record the reason for each material difference, the corrective action and evidence that the two sides now agree or that an approved exception remains.
Test failure conditions before routine use
Build a controlled test matrix. Include repeated requests, lost acknowledgements, temporary disconnection, invalid references, out-of-order updates and a restart during processing. Use test data and an environment where these exercises cannot trigger unintended customer or financial actions.
For each scenario, specify the expected business result. If the receiving system accepts an order but the acknowledgement is lost, a retry should not create a second business effect. If an amendment arrives too early, it should wait or fail visibly according to the agreed design.
Check recovery after a backlog. A connection may resume successfully while queued work overwhelms the destination or arrives in an unsuitable order. Observe how the integration drains pending items, how users see progress and whether urgent current work receives appropriate treatment.
Write the support procedure alongside the connector
Document how to identify an affected transaction, inspect its history, correct a business error and escalate a technical failure. State which actions require approval and which can be performed by routine support. Keep credentials and sensitive payloads out of general troubleshooting notes.
Agree a temporary operating process for extended outages. It should prevent duplicate commitments when normal service returns. If staff record work manually, define how those records will be matched and entered later, who checks them and how the original references are preserved.
Review recurring exceptions after launch. Frequent unknown items may indicate weak master-data ownership. Repeated manual replays may reveal unclear statuses. Treat these patterns as design feedback rather than accepting a permanent burden on support staff. To review your integration’s business rules and recovery behaviour, contact Maxicon with examples of delayed, duplicated or unresolved transactions.
Frequently asked questions
Why do duplicate orders appear after a connection timeout?
The sender may not know whether the receiver completed the first request. If it retries and the receiver cannot recognise the repetition, another order may be created. Stable request identity and tested duplicate protection help address this ambiguity.
Should every failed transfer retry automatically?
No. Temporary availability problems may justify retries, while invalid business data generally needs correction. Classify failures and assign the appropriate action. Automatic repetition of an invalid request usually delays resolution and makes the exception queue harder to manage.
Is a successful transfer message proof that the order is complete?
Only if the agreed acknowledgement represents completed business processing. Some acknowledgements confirm receipt alone. Define the distinction between received, validated and completed so users do not make commitments based on an intermediate technical status.
How frequently should reconciliation run?
Choose a frequency based on transaction volume, operational urgency and the consequences of a missed record. Some workflows need frequent checks; others can be reviewed at a scheduled interval. Ensure each review has an owner and a process for resolving differences.
Can staff manually create a missing order during an outage?
Only through an approved fallback that preserves references and supports later matching. Otherwise, the delayed original may arrive and create a duplicate commitment. The fallback must explain who records the action and how normal processing resumes safely.
Related technology support
For an additional service perspective related to this guide, explore Trubyte’s IT strategy and consulting services.
Discuss your requirements with Maxicon
Tell us about your business, current environment and the support you need.
