Two-way synchronisation needs explicit write rules

A connection may transfer data in both directions. That does not mean every field should be freely overwritten on both sides. Shared fields need a rule linking editing rights, the base version and conflict handling. Otherwise, a technically new message can bring back a value that is outdated for the business.

A late arrival may be based on older data

A fictional software company synchronises CRM and ERP. ERP confirms the billing address, while CRM maintains the project contact. This invented sequence shows what a blanket whole-record update could cause:

The message arrives later, but its address comes from an older version. If the integration accepted the whole record unchecked, the confirmed change could be lost. The labels v7 and v8 here refer to the same ERP record; unrelated local version counters from different systems cannot simply be compared.

Detect the base version and decide the conflict

Microsoft describes optimistic concurrency for Dataverse: an application can detect whether the server record changed between reading and writing. Which check is available and how to enable it depend on the product and its interface.

Detecting a difference does not decide which address is correct for the business. In this example, the old address should await clarification or be treated as an unauthorised write-back. Simply resending the rejected old value with a new version identifier would defeat the version safeguard without resolving the business difference. Nor does a single version check make every step across multiple systems atomic.

When both sides may write

If both teams genuinely need to edit the same information, a two-way solution may be appropriate. Permitted fields, changes and conflict decisions then need to be explicit. Microsoft’s dual-write documentation shows different directions per column mapping, for example; a shared switch for everything is not a business requirement.

Transferring different fields in different directions may also suffice. In this example, the new project contact should be accepted under its rule, while the old billing address should not be written back unchecked. Both values belong to the same customer but require different write decisions.

Sources

• Microsoft Learn — Optimistic concurrency

• Microsoft Learn — Customize table and column mappings