Sync Conflict Resolution for Two-Way Data

In a one-way sync, one system is the source and the other follows. Two-way sync is different: both systems accept changes, and sooner or later the same record will be changed in both places before the sync has caught up. A sales rep updates a customer's phone number in the CRM while someone in finance updates the billing address of the same customer in the accounting system. Or two people change the same field to different values within minutes. Sync conflict resolution is the set of rules that decides what happens next. Without explicit rules, the result depends on timing, and data is silently lost. This guide explains how to detect conflicts, choose rules that match how the business works and handle the cases rules cannot settle.

What counts as a conflict

A conflict occurs when a record has changed in both systems since they were last in agreement, and the changes cannot both be applied without one overwriting the other. Not every concurrent change is a conflict. If the CRM changed the phone number and accounting changed the billing address, a field-level sync can apply both. A true conflict is when the same field, or fields that depend on each other, changed on both sides.

Deletes create their own conflicts: one side deletes a record while the other updates it. So do creates, when the same real-world customer is entered in both systems before the sync links them.

Detect conflicts reliably

You cannot resolve what you do not detect. The sync needs to know, for each record and ideally each field, what the agreed value was at the last successful sync. Common approaches:

• Store the last synced value or a hash of it for each field, and compare both sides against it
• Use version numbers or modification timestamps from each system, recorded at the last sync
• Track changes through each system's change feed or audit log rather than comparing full records

Be wary of relying only on timestamps from different systems. Clocks can differ, some systems round timestamps and some update the modification time when nothing meaningful changed. Version numbers or stored previous values are more dependable.

Database replication tools have their own definitions. The PostgreSQL documentation on logical replication conflicts explains that incoming changes are applied even if the row was changed locally on the subscriber, that replication stops if incoming data violates a constraint, and that updates or deletes for missing rows are skipped and logged (PostgreSQL: Logical replication conflicts). If you build two-way sync on top of such tools, those defaults are part of your conflict behaviour, whether you chose them or not.

Sync conflict resolution starts with field ownership

The most effective rule is to avoid conflicts by design. Assign each field an owner: the system where it is normally changed and whose value wins. For example:

• The CRM owns contact details, sales stage and account owner
• The accounting system owns billing address, payment terms and credit status
• An ERP owns product prices and stock levels

The other system can display these fields and may even allow edits, but its edits either go back to the owner as a request or are overwritten. Field ownership turns most potential conflicts into ordinary one-way flows, and makes the remaining ones easy to explain to users.

Choose rules for shared fields

Some fields genuinely need to be editable in both systems. For those, pick a rule per field:

• Last writer wins: the most recent change wins. Simple, but it relies on trustworthy ordering and silently discards the other change
• Source priority: one system always wins for this field, even if its change was older
• Merge: combine values where that makes sense, such as adding tags or notes from both sides
• Manual review: hold the record and ask a person to choose

Whatever you choose, document it and make it visible to the people who use the data. Silent rules erode trust when users see their changes disappear.

Worked example: a hypothetical rule table

The table below is a hypothetical set of rules for syncing customers between a CRM and an accounting system. It illustrates how rules are assigned, not a recommended configuration.

FieldOwnerEditable in other systemRule on conflictCompany nameCRMYesManual reviewPhone and emailCRMNoCRM winsBilling addressAccountingNoAccounting winsPayment termsAccountingNoAccounting winsTagsSharedYesMerge both setsNotesSharedYesAppend both, labelled by sourceRecord deleted on one side, updated on otherNot applicableNot applicableHold for review; do not delete automatically

Queue the hard cases

Rules will not cover everything. Send unresolved conflicts to a review queue with both values, who changed each and when, and the rule that could not decide. Give the queue an owner and a target time for clearing it. If the same type of conflict appears often, change the process or the ownership rules rather than reviewing the same issue repeatedly.

Prevent loops and echoes

When the sync applies a change to system B, system B records it as a new change. Without care, the sync then sends it back to system A, which records it as a change again, and so on. Mark changes made by the sync itself, for example with a dedicated integration user or a source flag, and skip them when reading changes back. Our guide to Zoho CRM PostgreSQL sync shows how this works in a two-way design.

Tell users what the rules are

Conflict rules only build trust if the people entering data understand them. Add short notes to the relevant screens or training material, such as "billing address is managed in accounting; changes here are overwritten". Where a system allows edits to fields it does not own, consider making those fields read-only instead. Fewer surprises means fewer support requests and fewer manual workarounds that create new conflicts.

Log every decision

Record each conflict: the record, the fields, both values, the rule applied, the outcome and the time. These logs let you answer "why did my change disappear?", spot rules that are causing problems and prove what happened if data is questioned later.

Check for drift regularly

Even with good rules, systems can drift apart through missed events, failed retries or manual fixes made outside the sync. Run periodic reconciliation that compares records across systems and reports differences. Our guide to database synchronization covers finding and repairing drift.

Frequently Asked Questions

What is sync conflict resolution?

It is the set of rules that decides which value wins when the same record or field has changed in two synced systems since they last agreed.

Is last writer wins good enough?

For low-risk fields it can be. It depends on reliable ordering and silently discards the other change, so avoid it for important fields and prefer field ownership.

How do I detect a conflict?

Keep the last agreed value or version for each field and compare both systems against it. Avoid relying only on timestamps from different systems.

What should happen to conflicts rules cannot settle?

Send them to a review queue with both values and their history, owned by someone responsible for clearing it.

Keep two-way data trustworthy

We design two-way syncs with clear field ownership, conflict rules, review queues and reconciliation. See our real-time CRM and database synchronization service, or talk to us about sync conflict resolution.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.