Connecting two applications is straightforward compared with deciding which application is right when their records disagree. A customer address may appear in the CRM, the job system and accounts. If staff can change it in all three, a synchronisation rule can spread an error just as efficiently as a correction. Start integration design with ownership at the field level, then decide when and how changes should travel.
Map a single customer change
Imagine a Geelong wholesaler using separate sales and fulfilment systems. A customer asks sales to change its office address, while the warehouse still needs a different delivery address for an open order. A broad rule that copies every address everywhere would erase that distinction. List the actual fields and their purpose: billing address, default delivery address and order-specific delivery instructions. Assign each an authoritative source and identify permitted exceptions. Use a small mapping sheet that staff can understand, including examples of values that should deliberately remain different.
Distinguish events from current truth
An integration may receive a message saying that something changed, then retrieve the latest record before applying it. This can be useful when delivery order is uncertain. Stripe explicitly documents that its webhook events are not guaranteed to arrive in generation order; other providers have their own contracts. Do not assume every integration offers the same delivery behaviour. Ask the implementer to explain duplicate handling, delayed changes and updates that arrive after a record has been archived. Define the expected outcome for each using business examples.
Expose exceptions instead of hiding them
A silent synchronisation failure leaves staff making decisions from different versions of the same customer. Provide a visible exceptions queue with the affected record, the last successful update and the required next step. Avoid asking a general administrator to inspect raw technical payloads. They should be able to recognise a missing customer code or a mapping that needs review. Some errors can be retried safely; others need a human decision because two systems hold plausible but conflicting information. Give those cases a clear owner and resolution path.
Start with a narrow agreement
Choose one valuable flow, such as approved customer details moving into a new job, and document it end to end. Expand after the team can explain what happens when the flow fails. Your mapping should answer:
- Which application owns each field, including permitted local overrides?
- Does a change update existing jobs or only future ones?
- Who resolves conflicts and how is the resolution recorded?
- What visible signal tells staff that the receiving system is up to date?