Bidirectional Sync Is a Design Failure Most of the Time.
When a company asks for two systems to sync both ways, it is almost always asking for something else: permission not to decide which system owns the record. Sales wants to edit the customer in the CRM, finance wants to edit it in accounting, nobody wants the argument, so the request becomes "just keep them in sync." The connector vendor says yes, because the connector can. The sync runs. And then, for the life of the estate, the two systems take turns overwriting each other and the company pays for the argument it avoided, monthly, in reconciliation.
This post is about why bidirectional sync fails, what is actually being requested when someone asks for it, and the one narrow case where two-way is the right design.
The mechanism of the failure.
A two-way sync between systems A and B has to answer a question every time it runs: if A and B differ, which one wins? There are only three answers, and each of them is a way of losing data.
Last write wins. Whichever system was edited most recently overwrites the other. This is the default in most connectors and it means the correctness of the customer record depends on who happened to type last. A rep updates the phone number in the CRM at 9:00; finance corrects the legal name in accounting at 9:05; at 9:10 the sync carries finance's whole record back to the CRM and the phone number reverts. Nobody sees it happen. The rep assumes the sync is broken; finance assumes the rep never made the change.
A designated winner per field. Better, and it is what a careful implementation does: name and address from A, terms and limits from B. But look at what has happened. Each field now has exactly one owner and flows one way. The "bidirectional" sync has become two one-directional flows in a trench coat, and the design decision it was meant to avoid has been made anyway, only inside a connector's configuration screen where nobody will find it.
Conflict queues. The sync detects the disagreement and parks it for a human. This is honest, and it is a job: someone now reviews conflicts, daily, forever, deciding case by case which system was right. The queue is the cost of the missing decision, paid in a person's time.
There is no fourth answer. Two-way sync is not a way of avoiding the ownership decision. It is a way of making it badly.
The second failure: loops and echoes.
Even with a winner rule, two-way flows have a structural problem one-way flows do not. A changes, syncs to B; B's update fires B's own triggers, which may write back to A; A's write fires the sync again. Well-built connectors suppress the echo. Many do not, and the symptoms are familiar to anyone who has run one: records whose modified time updates every few minutes with no visible change, API limits hit by a sync talking to itself, and timestamps that make it impossible to know when a person last touched anything, which quietly breaks every report and every automation that keys on "recently modified."
What is actually being asked for.
Underneath almost every request for two-way sync is one of three real needs, each of which has a one-way answer.
People in system B need to see what is in A. They do not need to edit it. A one-way flow from A to B, with the fields read-only in B, gives them the view and removes the conflict. This is the system of record pattern and it covers most of the cases.
People in B need to change something that lives in A. The answer is a way to change it in A from B, an action rather than a sync: a button, a form, an approval that writes to A through its API and lets the one-way flow bring the result back. Zoho's own tooling is good at this; the CRM and desk integration is a worked example where support sees the customer from the CRM and raises changes rather than making them.
The two systems own different fields of the same record. Then say so, field by field, and build two one-way flows, each carrying the fields its source owns. That is not bidirectional sync. It is two integrations that happen to touch the same object, and it should be designed, documented and monitored as two.
The one case where two-way is right.
Genuine two-way sync is the correct design when the same fact is legitimately created and edited in both places by different people who cannot be routed to one system, and the business has decided, explicitly, that last-write-wins on those specific fields is acceptable. Calendar events between a CRM and a mail system are the usual example: a meeting moved in either place should move in both, and the cost of a rare overwrite is a rescheduled call, not a wrong invoice.
Notice the shape of that case: low stakes, symmetric editing, an explicit decision about the winner rule. If the record carries money, stock, a legal name or a customer's status, it fails the test, and it fails it because the cost of the overwrite is not a rescheduled call.
How to unwind one you already have.
Most companies reading this have a two-way sync running somewhere. The unwinding is smaller than it looks.
List the fields the sync touches and, for each, name the system where it is created and where people actually correct it. That is the owner.
Split the sync into one-way flows per owner. The connector platform will usually let you do this without new tooling; our comparison of Zoho Flow and Zapier covers what each can carry.
Make the receiving fields read-only in the receiving system, and give the people who used to edit them there an action that changes the owner instead.
Run a one-time reconciliation from the owner outward, and then stop reconciling, because the mechanism that created the drift is gone.
This is a few weeks of integration work on a Zoho estate and it removes a recurring cost that most companies have stopped noticing because it arrives as reconciliation rather than as a bill.
Why it matters more than it used to.
A person reading two disagreeing records applies judgment. A model, an automation or an AI agent reading them applies a rule, at scale, and a two-way sync guarantees the records will disagree in ways that shift by the hour. Every AI initiative on top of an estate with two-way syncs at its core inherits that instability. The ownership decision the sync was bought to avoid is the same decision the AI project will force, and it is cheaper to make it now, in a page, than later, in an incident.
We make it in discovery, which you pay for only if you proceed: the field-by-field ownership map, the one-way flows that replace the sync, and a guaranteed estimate for building them. If we estimate low, we absorb the difference. The estimate is usually small. The decision is the expensive part, and the sync was never going to make it for you.
Find out where your orders, inventory and invoices stop agreeing.
In a no-risk discovery we follow an order from sale to shipment to invoice across your systems and show where it breaks and what one connected system would change. You pay only if you proceed. Or see how we approach it.
More on the same problem:
Comments