Resolving Data Conflicts Between Systems That Both Think They’re Right

A customer updates their billing address directly through a self-service portal at 2:14pm. At 2:16pm, an account manager, unaware of that update, edits the same address field in the CRM based on information from a call earlier that day, using an address the customer had actually already moved away from. The sync between the two systems runs a few minutes later and, following its default rule, keeps whichever update has the later timestamp — which happens to be the account manager’s, the less current and less accurate one. Both systems now agree with each other. Both are wrong. And because they agree, nothing about the sync process flags this as a problem worth anyone’s attention.

Why “Most Recent Update Wins” Is a Default, Not a Decision

Most sync tools ship with a default conflict resolution rule of some kind, and the most common default is simply keeping whichever update has the latest timestamp. This rule has one real virtue — it’s simple and requires no configuration — and one serious limitation: recency has nothing to do with accuracy. A more recent update from a less reliable source is not more likely to be correct than an older update from a more reliable one, and a sync built on this default is quietly making a judgment about which source to trust without anyone actually having decided that’s the right judgment to make.

Distinguishing Fields Where Recency Is a Reasonable Proxy From Fields Where It Isn’t

Recency-based resolution works reasonably well for fields where whoever touched the field most recently really does have the freshest information — a support ticket status, for instance, where the most recent update genuinely reflects the current state of an issue. It works poorly for fields like contact information, where the update source matters more than the update timing, because a self-reported update from the customer directly is inherently more reliable than a secondhand update entered by an employee working from older information, regardless of which one happens to have the later timestamp.

Building Source-Based Priority Instead of Purely Time-Based Priority

Field Category	Recommended Resolution Rule
Customer-submitted contact/profile data	Customer-direct source always takes priority over internally entered data
Operational status fields (ticket state, order status)	Most recent update from the owning system is reasonable
Fields both systems can legitimately update	Flag for review rather than auto-resolving
Financial or compliance-sensitive fields	Require explicit confirmation before overwriting, regardless of source

Building resolution logic around which source is actually more trustworthy for a given field, rather than defaulting uniformly to whichever update happened most recently, requires more upfront thought but produces meaningfully more accurate results for exactly the fields where accuracy matters most.

Why Silent Resolution Is Worse Than No Sync at All in Some Cases

A sync that silently resolves a conflict, in either direction, without any visible record that a conflict happened at all removes any opportunity for a human to catch a wrong resolution before it causes downstream damage. This is arguably worse than having no automatic sync, because a fully manual process would have had at least some ambient human awareness of both updates happening. An automated sync that resolves conflicts invisibly creates the appearance of clean, current data while actually concealing exactly the situations where the data quietly became wrong. Logging every conflict — even ones resolved automatically according to a defined rule — at minimum gives someone the ability to spot a pattern of frequent, recurring conflicts on a specific field, which is itself a useful signal that something upstream needs attention.

When to Require Human Review Instead of Any Automatic Rule

For a smaller set of genuinely high-stakes fields — anything touching billing, compliance-relevant status, or a field where an incorrect value could trigger a downstream automated action with real consequences — the safest resolution rule is often no automatic rule at all. Flagging the conflict for a human to manually decide, rather than picking a winner automatically according to any rule, adds a small amount of friction and delay but avoids the risk of an automated system confidently resolving a conflict incorrectly in a case where the cost of being wrong is genuinely high. Not every field deserves this level of caution, but a deliberate, explicit decision about which ones do is worth making rather than applying the same automatic-resolution logic uniformly across every field regardless of stakes.

The Value of Reconciliation Reports, Run Regularly Rather Than Reactively

Even a well-designed conflict resolution scheme will occasionally get something wrong, particularly as data sources and system configurations change over time in ways the original scheme didn’t anticipate. Running a periodic reconciliation report — comparing key fields across both systems and flagging any that don’t currently match, independent of the sync’s own conflict log — catches drift that the sync’s own internal logic might have missed, especially in cases where a conflict occurred but wasn’t correctly detected as one by the sync tool itself due to some edge case in how the two systems format or timestamp their data.

Deciding This Before Building the Sync, Not After the First Bad Conflict

Conflict resolution logic is often treated as an afterthought during integration projects, addressed only after the first visible case of bad data causes a real problem downstream. Deciding on field-by-field resolution rules deliberately, before the sync goes live, based on an honest assessment of which source is actually more trustworthy for each field, produces a meaningfully more reliable integration than building the simplest possible sync first and only adding nuance reactively once specific failures have already caused damage that’s sometimes difficult to fully trace back and correct after the fact.

Two Systems Agreeing Isn’t the Same as Two Systems Being Right

The comforting appearance of two systems in sync, showing identical values for a shared field, says nothing on its own about whether that shared value is actually correct — it only says that whatever resolution rule the sync uses has, in this instance, produced a single agreed-upon answer. Businesses that build resolution logic around genuine source reliability, log conflicts rather than resolving them invisibly, and run periodic reconciliation checks catch the cases where agreement and accuracy have quietly diverged. Businesses that trust a default last-write-wins rule without examining it are trusting that recency and correctness happen to line up, which they often don’t, and the gap between the two tends to surface only once someone acts on data that both systems confidently, and wrongly, agreed on.