Why two-way sync is almost always the wrong default

Why two-way sync is almost always the wrong default

Every few weeks a prospect asks us to build a two-way data sync. The setup is usually the same. HubSpot and Salesforce. Notion and Confluence. Airtable and an internal Postgres. Two systems that need to "stay in sync". Both sides should be writable. Both sides should reflect each other within minutes.

We almost always say no.

Not because the work is hard. The work is interesting. We say no because we have built these systems before, watched them break, and watched the cleanup eat months of someone's life. Two-way sync is one of those ideas that sounds reasonable when you describe it in a meeting and becomes a liability the moment two people edit the same record on opposite sides at roughly the same time.

This article is longer than what we usually publish, because the topic does not fit into a bullet list. We want to explain what goes wrong, why the standard frameworks for thinking about this are misleading, and what we recommend in the cases where the customer's actual problem is real but the proposed solution is wrong.

The question nobody wants to answer

Sync sounds like a technical problem. It is a governance problem dressed up in API calls.

If two systems are supposed to hold the same piece of data, somebody has to decide what happens when they disagree. That sentence is the whole game. Most teams skip past it because the answer feels obvious in the abstract: take the latest change, or take the one from the more authoritative system, or merge them. In practice none of those answers survives contact with real data.

Take a contact's phone number. Marketing updates it in HubSpot because a data enrichment vendor delivered a refreshed list. Three hours later a sales rep updates the same number in Salesforce because the customer mentioned a new mobile in a call. Which one wins? Both people acted in good faith. Both systems believe they hold the correct answer. The sync engine, which has neither context nor judgment, has to pick.

You have three options.

You can pick the most recent write. This is the default in most sync tools. It works until it does not. A bug in HubSpot pushes a stale backup overnight and overwrites the sales rep's change. Nobody notices for a week, until the customer calls in and asks why their old number is being used again.

You can declare one side the source of truth. This is the most honest option. It is also no longer two-way sync. It is one-way sync with the polite fiction that the secondary side can write, knowing those writes will be overwritten the next time the master writes back.

You can split responsibility by field. HubSpot owns marketing fields. Salesforce owns sales fields. Both can read everything. Each side only writes its own fields. This is the only model that genuinely scales, and it is not really sync anymore. It is field federation with a sync transport.

When we walk customers through these options, most of them want option one. After we role-play three or four conflict scenarios, most of them prefer option three. And then the conversation usually drifts toward the question that should have started it: do we actually need two writable systems, or do we just have two tools that overlap because nobody made a call?

Sync loops, and how they bankrupt your Make subscription

Before we get to architecture, a technical note. Two-way sync has a failure mode that hits roughly nine out of ten implementations: the sync loop.

It works like this. System A changes. A webhook fires. The sync engine writes the change to system B. System B emits its own webhook because something changed. The sync engine writes the change back to system A. System A emits another webhook. The cycle repeats until something stops it.

In a well-designed system, the sync engine recognizes its own writes and ignores the resulting webhook. In a poorly designed system, or in a sync built with a tool that does not give you that level of control, the loop runs until it hits a rate limit, a quota cap, or an alert.

We had one client whose Make scenario was syncing contacts between Pipedrive and an in-house database. Every night between two and four in the morning, a separate batch import touched the same records. The sync engine could not tell those changes apart from human edits, so it dutifully pushed them to Pipedrive, which dutifully echoed them back, and the loop ran for two hours. Pipedrive shrugged it off. Make did not. The two-hour window consumed about eighty thousand operations, and by the second week of the month the client's Make account had burned through its entire monthly allowance. Their workflows just stopped working on the fourteenth, with no warning except a dashboard nobody was checking.

Preventing this is not trivial. You need to mark every change with its origin and have your sync logic refuse to act on changes it originated. Most SaaS platforms do not give you a clean way to do this. There is no "set this field, but do not fire a webhook" API. You end up writing workarounds. Compare timestamps. Compare hashes. Delay processing by thirty seconds. Each workaround is a place where the system can drift from your model of it. Each one becomes the cause of a future outage that you will spend hours diagnosing.

Two systems are never in the same state

Even when the loop is solved, you still have the consistency problem. Two systems cannot be in the same state at the same time. There is always a window in which one is ahead of the other. With webhooks and a fast sync engine, the window is seconds. With polling, it can be minutes or longer.

In practice this means a sales rep can save a note in Salesforce and, ten seconds later, open the same contact in HubSpot and not see the note. If they make a different edit in HubSpot at that moment, the two edits race. Whichever webhook arrives at the sync engine first wins. There is no deterministic answer to which one that will be.

We had a client whose primary customer record showed two different email addresses depending on which staff member looked at it. The cause was a four to six minute replication delay between HubSpot and their CRM. Two people had opened the customer in the same fifteen-minute window, each saw a different snapshot, each made an edit, and the sync engine resolved the conflict by keeping the older edit because its CRM timestamp happened to be slightly earlier. The "newer" change was, from a human standpoint, actually the older one. Neither user was wrong. The system was just doing what we had asked it to.

Distributed databases like Cassandra and DynamoDB have entire chapters of theory devoted to this kind of problem. They use vector clocks, CRDTs, and explicit tiebreakers, and they make the consistency model part of the API contract. SaaS tools do not. HubSpot, Salesforce, Notion, Airtable: none of them were built with the assumption that two outside systems would be writing to the same record in parallel. When you build a two-way sync on top of them, you are smuggling in a distributed-systems problem that the platform is not equipped to help you solve.

Where two-way sync actually fits

There is a narrow band of cases where two-way sync is the right call. In four years we have seen it maybe a tenth of the time.

Case one: both systems are genuinely peers, with separate teams that legitimately need to write to the same record, and the organization has the discipline to maintain a conflict resolution process. We have built this for one client, a financial services firm with two business units, each running its own CRM, with shared customers between them. Conflicts go to a weekly review meeting. A person, not an algorithm, makes the call.

Case two: the synced fields are monotonic. "Last login timestamp" can only increase. If both systems carry it, the later value automatically wins, and conflicts are mathematically impossible. There are not many such fields in CRM data, but they exist in some operational contexts.

Case three: writes are so rare that conflicts effectively never happen. If marketing touches a record once a month and sales touches it once a week, the chance of a true collision is small enough to ignore. But this is also a case where you should ask whether you need a sync engine at all, or whether a weekly export and a polite Slack ping would do the job for a fraction of the cost.

Outside those cases, our answer is almost always one of two alternatives.

Alternative one: source of truth with read-only copies

Pick one system as the source of truth. Every other system gets a copy, refreshed on a schedule. Writes go into the source of truth. The copies update themselves at the next sync.

This sounds restrictive. It is. It is also the only model we have seen that consistently survives in production for more than two years without accumulating data quality debt.

For the HubSpot and Salesforce case, this usually means Salesforce is the source of truth for contact data. HubSpot gets a half-hourly refresh and uses the data for segmentation, list building, and campaign personalization. If a marketing user needs to update a contact, they do it through an embedded Salesforce form, or through a workflow that writes to Salesforce and then waits for the next refresh to see the change reflected in HubSpot.

The user experience is initially worse than two-way sync. People are used to seeing their changes immediately. They have to learn that the change went somewhere, but the system they are looking at will catch up in a few minutes. After a week or two, this stops being a problem. The tradeoff is enormous: no conflicts, no loops, no audit nightmare, no quarterly data quality fire drill.

Which system you pick as the source of truth is a political question, not a technical one. It is a statement about whose data wins in a fight. If you pick Salesforce, you are saying that sales wins. If you pick HubSpot, you are saying that marketing wins. The decision belongs to whoever owns the customer data conceptually, which is usually the CEO or whoever runs revenue. It does not belong to your automation team. We have refused projects where the customer wanted us to pick for them.

Alternative two: field federation

Split ownership by field, not by system. HubSpot owns newsletter opt-in, marketing persona, last campaign sent. Salesforce owns deal stage, last contact, next step. Each system can read the other's fields, but only writes its own.

This is what we end up with most often when the customer has legitimate writing needs on both sides. It is harder to roll out than the source of truth model because staff have to learn which fields live where. We address this by hiding or graying out non-writable fields in each UI when possible. When it is not possible, we publish a one-page guide and put a link to it in every onboarding email for the affected teams.

For one client we built this with about eighty fields across the contact record. We made a spreadsheet with four columns: field name, owning system, reading systems, write rules. The spreadsheet became the authoritative document. Any new field requires an entry in the spreadsheet before any sync is built. Two years later, the spreadsheet has grown to about a hundred and twenty fields, and the sync has not had a conflict-related incident in eighteen months.

The work to set this up is more than the work to build a naive two-way sync. The work to run it is dramatically less. We bill our customers for the second number more than the first.

If you must build it anyway

Some customers, after all the warnings, still want two-way sync. We do it, with a damage control plan.

We log every conflict. Each detected disagreement goes to a separate database with timestamps, both versions, the chosen resolution, and a reference to the source records. This is the only way to reconstruct what happened after the fact, when somebody complains that their edit was lost.

We escalate ambiguous conflicts to a human. Not every conflict is resolvable by rules. When the system cannot decide, it creates a task for a designated person, who picks the right version and writes it back. This is slow and expensive. It is also the only honest way to keep data quality in a true two-way sync.

We rate-limit the sync engine. The sync logic is allowed only so many writes per minute. If it tries to exceed the cap, it stops and alerts. This is insurance against sync loops. It will not prevent them entirely, but it will keep them from running for two hours undetected.

We schedule audit runs. Once a week, a process iterates over every synced record and compares both sides. Discrepancies go into a report. A person reviews the report and decides what to do about each one.

Together, these four controls add real cost. They are the price of a serious two-way sync. In most cases, doing one of the alternative architectures from the start is cheaper, even after counting the political work to get the customer to accept it.

The question behind the question

When a customer asks for a two-way sync, we ask why. What problem is the sync supposed to solve?

The answers fall into a small number of buckets.

"So both teams see the same data." For this, a one-way sync from system A to system B is enough, combined with the rule that writes happen in A. Both teams see the same data. Only one of them can change it.

"So staff can work in whatever tool they prefer." This is usually a polite version of "we bought two overlapping tools and nobody wants to give one up". The honest solution is consolidation, not sync. Sync papers over the duplication and locks it in.

"For flexibility, in case we change the master later." This is the most expensive answer. You are paying real implementation cost today for an option you will probably never exercise. If you do change the master system later, the migration will be its own planned project. It does not benefit from a sync architecture you built two years ago for a different reason.

"For resilience, if one system goes down." Two-way sync does not make you more resilient. It makes you more fragile. If one system is unreachable, the sync stops, and the two sides drift. When the other system comes back, you have to reconcile. Resilience comes from backups and from clear failover policies, not from sync.

When we ask the question, the customer usually answers more carefully on the second attempt. The answers get less abstract. They reveal that the real problem is something else, sometimes something organizational that no sync engine can fix.

Symptoms that your sync is hurting you

Sometimes we get called because the sync is "not behaving as expected". The patterns below show up in almost every case. If three or more of them describe your situation, it is time for an honest review.

First symptom: the operations team maintains a "correction list". A spreadsheet, a Notion page, a Trello board, anything that holds records "to be checked manually after the sync". If you have one, your sync is not the mechanism it claims to be. It is a partially automated copy machine with a manual cleanup queue attached.

Second symptom: monthly data quality reports show fluctuating numbers without any change in operational reality. If the share of "complete contact records" reads 87 percent one month, 91 the next, 84 the next, depending on the day of measurement, your data consistency is suffering. The fluctuation comes from conflicts being resolved differently depending on who happened to write last.

Third symptom: employees have built workarounds to bypass the sync. They keep customer data in a private Excel file because they no longer trust the central system. They check with a colleague before making important edits, to make sure the colleague is not editing the same record. These workarounds emerge when the system is not doing what its users need.

Fourth symptom: support tickets often contain the phrase "the data changed without anyone touching it". This is the classic sync loop fingerprint. When employees report that fields revert overnight, somewhere a sync loop is running that overwrites their edit.

Fifth symptom: nobody can clearly identify which workflow triggered a conflict. The logs are incomplete or scattered across three tools. A conflict investigation takes two hours because you have to hop between Make, the ERP, and the CRM to reconstruct the event chain.

Sixth symptom: platform costs for the sync have grown more than 30 percent in the past year, without a matching increase in data volume. That is a sign of growing conflict-resolution operations, retroactive corrections, and repeated failed writes that get retried again and again.

These symptoms rarely appear in isolation. If you see one, look for the others. In most audits where we ask about these patterns, the team finds several. That is the point at which the migration discussion needs to get serious.

Migrating away from a sync you already built

We also get the other call. "We built a two-way sync two years ago. It is not working. Can you help us get out of it without stopping operations?" The answer is yes. The path is longer than most expect.

Step one: measure what is actually happening. Before changing anything, we want numbers. How many conflicts occurred in the last month? How many records are different across the two sides? Which fields produce the most disagreements? This measurement is usually uncomfortable, because it surfaces problems people had been quietly ignoring. It is also the only basis on which a migration plan makes sense.

Step two: decide field by field who wins. We use the federation spreadsheet as a template. The decisions are political and get made with the affected business teams. Sometimes we discover at this point that there are not nearly as many disputed fields as the team had assumed. Most fields belong cleanly to one side or the other once the question is asked explicitly.

Step three: technically remove write rights on one side. This is the hardest step. You have to explain to users why, starting Monday, they can no longer edit certain fields in the system they are used to. There is always resistance. We recommend doing this in waves: five to ten fields per week, with advance notice, with clear pointers to where those fields are now edited.

Step four: switch the bidirectional sync off and replace it with a one-way one. This is technically the easiest part once the first three steps are done. Most sync engines have a direction switch that flips from bidirectional to A-to-B. Flipping it turns a complex architecture into a simple one.

We have run this migration for three clients. It takes between six weeks and four months, depending on how many fields are involved and how much political resistance shows up. It is never fast. It is always doable. The result is a data architecture you can still maintain in two years.

What the platforms understand, and what they do not

Not every platform handles two-way sync the same way. A few observations from the field.

Zapier's out-of-the-box integrations have almost no conflict resolution. A "two-way sync" Zap is usually two separate Zaps running in opposite directions, with all the consequences. The loop prevention amounts to crude timestamp comparisons that fail in non-trivial scenarios. For serious two-way sync, Zapier is the wrong tool.

Make.com gives you more control per operation. You can set explicit markers, compare headers, filter webhook sources. That makes it a better fit than Zapier for two-way sync, and also significantly more work to set up. One implementation took us six weeks to model the conflict handling cleanly.

n8n, with its JavaScript option, offers the most theoretical room. You can express arbitrary conflict logic in code. You can integrate libraries that handle last-writer-wins with explicit tiebreakers. The downside: you leave the visual layer and land in something not meaningfully simpler than a custom microservice. If you are already there, you should consider whether a microservice that solves exactly this one problem would be cleaner.

Specialized tools like PieSync, which was acquired by HubSpot and folded into Operations Hub, or Census, try to solve the problem at the architecture level. They are visibly better than the generic workflow tools for real sync scenarios. They also cost significantly more, and they only work for the integration paths they explicitly support. If you have a very standardized architecture, they can cut implementation time meaningfully. If you have anything custom, you end up bolting on workarounds again.

A general observation. The more control a tool gives you for conflict handling, the more responsibility you have to take. There is no sync that "just works". There is only sync that works until the first real conflict shows up.

One last story

A few years ago a client moved to a new HR system. The old system was supposed to stay live for some legacy reporting. HR wanted two-way sync so that updates would flow in both directions, "just in case someone touches the old system by accident".

We sat down for three hours and walked through every conflict case we could imagine. At the end, we proposed something different. The new system would be the source of truth. The old system would be overwritten once a night with a snapshot. Reports against the old system would be at most twenty-four hours stale, which was fine for historical purposes. Writes in the old system would be technically disabled.

The build took two weeks. A real two-way sync would have taken four, plus ongoing conflict resolution, plus weekly audits. Over three years, the "easy" two-way sync would have cost six to eight times what the chosen design cost, with no real benefit.

Three months in, the HR director told us the old system was barely touched anymore. The parallel write capability that they had insisted on as essential turned out to be unnecessary. Six months in, the old system was retired.

This does not always happen. Sometimes the second write path is genuinely needed. But our experience is that the question of whether it is genuinely needed is asked far too rarely. It is assumed because the framing of the original request was "we need both systems to be in sync".

Closing

Two-way sync is not a feature. It is an architecture decision with significant downstream cost. Built without explicit conflict resolution, sync loop prevention, and a stance on eventual consistency, it accumulates data quality problems that become unfixable after twelve to eighteen months.

In the great majority of cases, one of two alternative architectures is the better fit. Source of truth with one-way sync to read-only copies. Or field federation, with each field owned by exactly one system. Both produce less complexity, fewer conflicts, and less ongoing maintenance load. Both are sometimes more work to set up than a naive two-way sync. Both are much, much cheaper to run.

If you are weighing a two-way sync between two business systems right now, a thirty-minute architecture conversation is worth more than a dozen support tickets later. In our free Automations Check we go through the question with you. The answer is usually that you do not need a two-way sync. You need something that looks like one from the outside, with much less risk on the inside.