Bidirectional Sync: How We Handle Conflict Resolution

One-way sync is easy: system A is the source of truth, system B mirrors it, done. Bidirectional sync is a different beast. When the same record can be edited in two places between sync runs, you need a principled answer to the question: which change wins?

This post walks through how FluxCascade detects and resolves conflicts, and the design decisions behind it.

What counts as a conflict

A conflict happens when the same field on the same logical record changes in both systems since the last successful sync. A phone number updated in HubSpot and the same contact's phone number updated in Jobber is a conflict. Two different fields changing on the same record is not — we merge those cleanly.

That distinction matters because it dramatically reduces how often you actually need conflict resolution. In practice, most concurrent edits touch different fields and merge without intervention.

Detection: field-level change tracking

After every successful sync, we store a compact snapshot of each synced record's mapped fields. On the next run, we diff each side against that snapshot — not against each other. This three-way comparison tells us exactly which side changed each field.

Comparing the two systems directly would only tell you the values differ, not who changed them. The snapshot is what turns "these disagree" into "side A edited this field, side B did not."

Resolution strategies

When a true field-level conflict is detected, the mapping's conflict policy decides the outcome. FluxCascade supports four strategies, configurable per mapping:

• Latest wins — the most recent edit (by source-system timestamp) is kept
• Source of truth — one system always wins for this mapping
• Field-level priority — choose a winning system per field, e.g. CRM wins for lifecycle stage, field tool wins for job status
• Manual review — the sync pauses that record and surfaces the conflict in your dashboard for a human decision

Why we default to manual review for destructive cases

Automatic policies cover the common cases, but a few situations are dangerous enough that we always pause: a field being cleared on one side while edited on the other, and record deletions with concurrent edits. Losing data silently is the one failure mode an integration platform can never have.

Paused conflicts show both values side by side, with the change history that led to them. Resolving one takes a click, and you can apply the same decision to similar conflicts in bulk.

Lessons learned

The biggest lesson: conflicts are a UX problem as much as an algorithms problem. Detection has to be precise, but what builds trust is being able to see what happened and why. Every sync decision FluxCascade makes is recorded and inspectable — and that transparency is what lets teams turn on bidirectional sync with confidence.