Sync Conflict Resolution

Sync conflict resolution is the rule that decides what happens when the same record changed on both sides of a two-way integration between syncs — someone updated the deal amount in the CRM while someone else updated it in the billing tool, and now two values claim to be current. Every bidirectional sync needs an answer to this, and the answer is frequently a default nobody chose, which is why the question is worth asking during evaluation rather than discovering it after a month of quietly overwritten edits. The common strategies trade off differently. Last write wins is the default almost everywhere: whichever change carries the later timestamp survives. It is simple and it silently discards the other edit, which is fine for a description and much less fine for a price. Worse, it depends on clocks and on when the sync ran, so the winner is sometimes the earlier edit that happened to be processed second. Source of truth per field is the strategy most worth the setup effort: designate one system as authoritative for each field — the CRM owns the account owner, the billing system owns the plan — so conflicts on that field cannot arise. A manual review queue holds conflicting records for a human to resolve, which is right for small volumes of high-value records and unworkable at scale. Some tools support merge rules that combine both changes when the fields differ within a record. What to check before you rely on a connector: which strategy it uses and whether it is configurable at field level rather than only globally; whether losing edits are logged anywhere or vanish; how deletions are treated, since a delete synced as an update or vice versa is the most destructive version of this problem; and how the first sync behaves, because the initial reconciliation of two populated systems is one large conflict wearing a different name.