Define an authoritative source for each field and each stage of the workflow before wiring two systems together. A single system need not own every customer fact, but two systems must not overwrite the same value without an explicit conflict policy. Faster synchronisation cannot fix ambiguous ownership.
Separate identity from editable attributes
Maintain a stable mapping between customer identifiers in both systems. Email addresses, phone numbers and names can change; none should be the only permanent integration key. Review duplicate organisations, branches and distinct legal entities rather than merging records because their names look similar.
For example, CRM might own relationship contacts while ERP owns the verified billing identity. This is a possible design, not a universal rule. A legal-name change after an invoice is issued may require a finance workflow rather than a blanket update to historical documents.
Specify the ownership contract
| Information | Example authority | Required rule |
|---|---|---|
| Account manager | CRM | Other systems receive a display copy. |
| Verified billing name | ERP | Conflicting changes go to review. |
| Sales opportunity stage | CRM | Do not equate it with fulfilment state. |
| Available stock | Inventory system | Recheck before committing an order. |
| Invoice settlement | Financial payment record | Use verified evidence, not browser clicks. |
For each row, document direction, acceptable delay, correction owner and history requirements. If a source is unavailable, decide whether to show the last known value with its timestamp, pause the operation or queue it. Avoid presenting stale data as current.
Test disorder and repetition
Integration events can arrive late, more than once or out of order. Use stable operation identifiers and the source’s versioning guarantees where available. Do not assume clocks across systems provide a sufficient conflict strategy.
Test a current update followed by an older one, a timeout during order creation and a repeated delivery. These must not create duplicate customers or revert an approved state. Provide an exception queue operators can understand rather than requiring direct database edits.
Reconcile the outcome
A successful API response is not proof of commercial correctness. Compare representative records, totals and exceptions, record differences, and assign approval for corrections. Logs should not contain credentials or unnecessary personal information. Limit integration accounts to required operations.
Our integration service addresses the exchange contract; custom business systems can support operational exceptions. See reliable webhook handling for delivery-level safeguards.
Sources and editorial status
- Microsoft: anti-corruption layer.
- Stripe: duplicate webhook events, a provider-specific example, not a guarantee about other APIs.
- Original contribution: field-ownership contract and reconciliation scenarios.
