A sales representative corrects a telephone number in the CRM. An integration receives an older form submission and writes the old number back. Both systems completed their requests, but the useful correction disappeared.
This is a synthetic example. The design below is a proposal for reviewing field ownership, not a tested connector or a client result.
Give each field an authority rule
Before implementing two-way synchronisation, write down which system may change each field, under which conditions, and what should happen when the systems disagree.
A small agreement might look like this:
| Field | Proposed authority | Conflict action |
|---|---|---|
| Original enquiry source | Source event recorded at first receipt | Preserve the original and record later touchpoints separately |
| Telephone number | CRM after a person verifies a correction | Send a conflicting incoming value for review |
| Assigned salesperson | CRM routing process and authorised operators | An enrichment job must not overwrite it |
| Marketing permission | Approved consent process | An ordinary contact update must not change it |
These are example rules, not universal defaults. The business must approve the meaning of each field. Marketing permissions need a separately reviewed process appropriate to the jurisdiction and actual systems.
“Newest” needs a definition
The latest arrival is not necessarily the latest business change. A delayed event can arrive after a more recent correction. A timestamp also needs a defined source and meaning.
Record separately:
- When the business change occurred, if the source reliably supplies that information.
- When the integration observed the event.
- Which version of the destination record was read before a proposed update.
If the source supplies no reliable version or change time, preserve that uncertainty. Don’t silently invent an ordering rule from the arrival time.
Before a write, check whether the destination changed since it was read. Use the platform’s supported conditional-update or version mechanism where available. If it offers no suitable mechanism, explain the limitation and choose an appropriate review or single-writer approach. A read followed by an unconditional write does not itself prevent a concurrent edit.
Define empty values separately
A missing field, an empty string and an explicit instruction to clear a value can mean different things. An update contract should distinguish them.
For example, a form that doesn’t ask for a telephone number should not automatically erase a verified number already held in the CRM. An authorised deletion request needs its own explicit handling and audit trail.
Make conflicts visible to an operator
A useful conflict record identifies the field, the proposed value, the current authoritative value, the source event, and the reason the update was held. Restrict access and avoid copying unnecessary personal data into chat alerts.
Give the operator a clear decision, with an inspectable history. Reprocessing the same event should preserve that decision rather than repeatedly creating a new unresolved task.
Agree acceptance tests before enabling writes
Use synthetic records in an authorised test environment:
- A delayed form event arrives after a verified CRM correction. The agreed authoritative value remains intact, and the conflict is inspectable.
- A contact update omits a field. The existing value follows the approved missing-value rule.
- The destination changes between reading and writing. The update is rejected, reconciled or held according to the supported concurrency design.
- The same event is delivered again. It produces no extra intended business change or duplicate review task.
- A source changes a marketing field outside the consent process. The ordinary synchronisation path does not treat that as permission to change consent.
These are expected behaviours to verify, not reported test results.
Start with one workflow and a few fields. An ownership agreement small enough for an operator to understand is more useful than connecting every editable field and discovering the conflict policy later.
Written for StackEndBox’s engineering publication. StackEndBox offers CRM and workflow integration scoping. Supported systems, evidence, delivery capacity and commercial terms are confirmed for each engagement. This article was prepared with AI assistance.
Top comments (0)