Synchronise data without uncontrolled overwriting

Assign an owner for each piece of information

Avoid declaring that the CRM is always authoritative when important details are actually reviewed elsewhere. Divide ownership by field or coherent group. For example, the CRM may own the account manager and commercial contact, while accounting owns approved billing details. The integration must recognise changes from another direction and handle them according to that agreement rather than automatically preferring whichever message arrives last.

Also explain how an employee requests a correction when they cannot edit the authoritative source. Otherwise an informal workaround emerges: somebody edits the destination, and the next synchronisation reverses the change. What looks like user error may reflect an incomplete operating process. Ownership becomes useful only when employees know where a correction belongs and who can approve it, including situations involving temporary access restrictions or staff absence.

Make a change identifiable

A useful change contains more than a new value. You need to know the object, originating system and version on which the decision depends. A local receipt timestamp establishes only when your integration observed a message. Delayed delivery can cause an older change to arrive after a newer one. That ordering matters when an update would replace information already reviewed by another employee.

Where available, retain the source version or change reference and record the latest successfully applied version. Where that capability is unavailable, investigate another control, such as fetching the current source state. Do not present a locally generated timestamp as a universal solution. The appropriate approach depends on the actual API, concurrent editing and the business consequences of retaining or overwriting the wrong value.

HTTP specifies conditional requests, including If-Match. An API can use such a condition to make an update depend on a previously known representation. Investigate whether the actual endpoint supports this facility and which version information it uses; merely using HTTP does not establish that support.

RFC 9110: HTTP Semantics ↗

Separate changing a value from clearing it

An absent field can mean that it was omitted, the source does not know the value or somebody intends to remove existing information. Translating all three situations into an empty destination field can silently erase useful data. Define which meanings are possible for each field and how the destination operation represents them. A partial update and a complete replacement should not be confused.

Test a fictional customer whose address changes without a new telephone number being supplied. The address update should not automatically erase the existing telephone number. Then test an explicit instruction to remove an obsolete number. The expected outcome differs even if the incoming field looks empty in both cases. Make intent observable in the input and acceptance criteria, rather than relying on a developer to guess it later.

Conflicting values differ from processing the same operation twice. Examine that distinction too: Prevent duplicate orders and invoices when API messages repeat.

Design a deliberate conflict route

A conflict can occur when two authorised employees edit the same address before an exchange finishes. Do not silently choose last arrival wins. You could give one source authority, combine independent field changes or ask a person to decide. Each choice needs a reason. A controlled financial reference may warrant a different rule from an informal commercial note, even on the same customer record.

Make review practical. Show the relevant previous value, competing proposals, source references and the business question that requires an answer. Record the reviewer’s choice and reason. The integration should then continue without presenting the identical conflict on every run. Preserve enough decision evidence for recovery, while avoiding an unlimited duplicate store of sensitive source content in technical logs or notification channels.

Prevent changes bouncing between applications

When an integration edits an address in application B, B may emit another event. Without recognition, that event can update A and start another round. Unnecessary API requests, notifications or modification timestamps can occur even if the displayed value is unchanged. A loop is therefore not always obvious as text repeatedly switching between two alternatives on screen.

Document how the integration recognises its own work. Possibilities include an operation reference, comparison against the intended state or refusing to write back fields owned by the other application. Test normalisation as well: a product may adjust capitalisation or remove spaces. The comparison should recognise meaningful changes without dismissing every difference. State which formatting variations are equivalent and which differences affect the business process or require review.

Treat archiving and deletion separately

Archiving a customer may stop new sales while retaining previous documents. Removing a contact does not automatically authorise the same action in every connected administration. Define the business event and the permitted consequence in each application. Involve the responsible owner in retention and access decisions instead of treating deletion as a simple technical mirror of another system’s state.

A bounded initial design might send removal requests for review while processing archive status automatically. Test what happens when an old message arrives after archiving. Without a rule, a closed record could become active again. Acceptance must therefore cover sequences, not just one final snapshot. Check whether the integration respects the later decision when an earlier update is retried, replayed or discovered during a reconciliation process.

Make processing delays visible

A working connection does not prove that records are up to date. Monitor the latest relevant source change processed and the work still waiting. Show whether reconciliation has actually run. A fresh status based only on a successful technical ping can mislead employees when business processing has been stalled for hours and previously copied values are no longer reliable.

Set a tolerance suited to the process. A daily report and an afternoon delivery schedule have different needs. Agree the response when information becomes stale: warn, pause consequential actions or consult the source directly. The employee should know whether the displayed value supports the decision they are making. A visible warning without an owner or next action does little to resolve the underlying backlog.

Test changes as a sequence

Create a trial containing a first change, a second change, delayed delivery of the first, a repeated message and a manual correction. After each step check which business value should remain. Include a restart to show whether the integration reuses its stored identity and version decisions. This reveals errors that a set of isolated successful requests cannot demonstrate.

Keep the expected business outcome alongside the execution history. When a test fails, investigate which ownership, ordering or interpretation assumption was wrong. Do not merely change code until one example turns green. Synchronisation is manageable when the rule remains explainable across representative cases. Use the findings to update the field contract and employee instructions together, so the technical implementation and daily operating process continue to express the same decisions.

Turn the explanation into a project decision

Record your assumptions, unknowns and acceptance checks in the matching tool. Use the service guides to discuss delivery and scope.

• API integration ↗
• CRM integration ↗

Questions about this topic

Continue with a related question