Choose ownership for each field
Determine which system owns each field: customer, price, order status or invoice. Two-way synchronisation needs rules when both systems change the same field. Document which value wins and why. A diagram with two arrows does not resolve conflicts or establish ownership.
Design safe repetition
Include business identifiers that recognise an already processed operation. Test a duplicate event and a delayed response. Decide which actions can be retried automatically and which need review. The aim is to prevent a retry from creating two orders or reporting an uncertain operation as complete.
Make failures visible
Record state, time, entity and a useful error cause without unnecessary sensitive information. Define who receives the alert and how processing resumes. Separate permanent rejection from temporary unavailability. A dashboard that shows only successes leaves the team without an explanation when records are missing.
Agree reconciliation
Beyond individual events, periodically compare record sets and totals between systems. Define tolerances and business exceptions. Test disconnection and recovery using test data. The integration agreement should state the expected update frequency and acknowledge the actual limits of the source systems.
Worked example: an order with a late response
Suppose the CRM sends an approved order to the ERP with a stable business reference. The connection times out before confirmation. Either the ERP did not create it, or it did and the reply was lost. The connector looks up that reference or uses the safe-retry mechanism supported by the API before deciding to retry. If it cannot verify the outcome, it marks it uncertain and requests review rather than blindly creating a second order. An operator should see the reference, state, last attempt and proposed action. This describes a design requirement; the actual implementation depends on the verified capabilities of each API.
Acceptance tests for the connector
Use cases covering new, duplicate, cancelled, incomplete and business-rejected orders. Add connection loss before and after possible creation. Verify that duplicates do not add records, uncertain outcomes remain visible and corrections can be reprocessed under control. Compare references in both systems at the end, not only totals. Also test revoked permissions, usage limits and credential protection. Document which failures recover automatically and which require a person. The scenario is not accepted merely because it works when every response arrives on time; its failure and recovery behaviour is part of the deliverable.
Key takeaways
- Recovery is part of the integration, not an afterthought.