When two systems write the same field, whose value wins

You change a price in your store. An hour later it is back to what it was.

Nobody touched it. No error appeared, no alert fired, and the sync log for that hour says the run completed successfully. Somewhere in your stack another system believes it owns that number, and once an hour it puts its own answer back.

The diagnosis is nearly always the same. A connector exists to sync catalogue data from an external source, a supplier feed, an ERP or a point-of-sale system, and by design it treats that external price as the source of truth. When you edit the price in the store by hand, the connector's next scheduled run sees a mismatch against its own copy and pushes the original price back.

The important words are by design. Nothing broke. The system did what it was built to do, and the only person who did not know the rule was the one who owned the shop.

"Sync" hides a decision nobody remembers making

Connect two systems that both hold a customer address, a price and a stock figure, and you have created a question: when both of them have a value for the same field, which one is right?

That question has to be answered field by field. Address might belong to the store. Cost price might belong to the supplier. Stock might belong to the warehouse. In a healthy setup each field has exactly one system allowed to write it, and every other system reads.

The trouble is that this decision is rarely made out loud. It gets made by whichever connector was installed, in whatever direction its developer chose, and the owner finds out months later from a customer.

Some vendors do state it. Linnworks answers the question in its own API documentation with no ambiguity at all: "Linnworks is the source of truth and therefore all inventory updates should happen in Linnworks." Xero's inventory product is equally direct: "Syncing a product with Shopify overwrites the product details in Shopify if a product with the SKU code already exists in XIP" - XIP being Xero Inventory Plus, the system that owns the record. Shopify names itself the system of record for marketplace listings once its connector is linked - though that statement lives in a migration help article rather than anywhere a buyer would look.

Intuit's connector documentation goes furthest, and explains the mechanism in the same breath:

"If there were any manual changes done to stock levels within eCommerce systems, these will only be overwritten when QuickBooks receives new updates from QuickBooks Online. The reason for this is that we do not get any notifications from the eCommerce system when stock is manually updated."

Read that twice. The connector overwrites your manual edit, and the stated reason is that it never learns the edit happened. That is not a defect being confessed. It is the architecture, described accurately.

The four conditions that produce a lost edit

Any three of these are survivable. All four together produce the wrong price, the wrong stock figure or the parcel at the wrong address.

The sync runs on a clock rather than on the change. Xero's runs hourly. Someone who builds these integrations summarised the general case: "most apps say 'real-time' but actually check every 10-15 min, so during busy periods you're selling from stale numbers." Between wake-ups the field is unguarded.

Event-driven syncs narrow that window without closing it, because events do not arrive in order. Shopify says so plainly in its developer documentation: "Shopify doesn't guarantee ordering within a topic, or across different topics for the same resource." A stale update can land after a fresh one.

The writer never compares timestamps. A connector told that the ERP owns the price reads the ERP value and writes it, without asking when the store's value was last touched. Shopify recommends using the timestamps it provides for exactly this - and recommends is the operative word. It is optional, so a value written five minutes ago loses to a value read five hours ago.

Nothing anywhere records that a conflict occurred. No before-and-after pair, no conflicts list, no divergence report. Both systems now agree on the wrong value, and the audit trail contains one ordinary successful update.

The technical name for the result is a lost update. Your edit was not rejected. It was accepted, and then buried.

The protection exists, and it covers one field

Shopify built the correct mechanism, which makes it a good demonstration of how narrow this kind of safety usually is.

When an app changes an inventory quantity, it can state the value it believes is currently there. If the real value has moved since it looked, the write fails rather than lands. Shopify's own description of the outcome: the mutation fails with a stale-quantity error, "preventing unintended overwrites".

That exists for inventory quantity. It does not exist for a price, a product title, or a shipping address. For those fields a connector's write simply succeeds. There is no way for it to fail safely, because there is nothing to compare against.

QuickBooks Online does something similar with a version number on each record - an attempt to save using an old version is rejected outright. Worth noting what that does and does not give you: the platform detects the collision, and then resolves nothing. The stale writer is turned away, and it is the connector's job to notice, re-read and try again. Whether your connector does that is a question worth asking, because the failure is invisible from your side either way.

What merchants actually lose

The price example is the mild version. The reviews of one widely used marketplace connector contain the sharper ones.

"The app overwrites or removes any changes you make on eBay with every sync, including products that were listed before you installed the app. So be sure to make all edits within the app. After I synced my existing listings it removed all the details like category, color, material, department, etc."

"Make all edits within the app" is the correct rule. It was learned by losing the data first.

Another review is a precise description of missing field-level ownership:

"EVERY TIME a product is sold on my shopify store it goes back and overwrites the details I have updated on Etsy. The connection I required was simply to update the quantity."

That merchant wanted one field synced. They got every field synced, because the connector's unit of work is the whole record.

Addresses do it too. A repeat customer moves, you correct their default address, delete the old one, and the next sync brings the old address back from whichever system still holds it.

And when the owning system is wrong, its wrongness propagates with full authority. A point-of-sale outage that reports every stock level as zero is faithfully copied downstream by a connector that trusts the owner, and the online store shows hundreds of products as unpurchasable until somebody switches the sync off by hand. The reader had no sanity check. Garbage from the owner is still from the owner.

Where "two-way" means "last write wins"

The phrase to be careful with is bidirectional. It describes the integration, not the field, and each field inside still moves one way.

Zapier is refreshingly blunt about its own limits: "Zapier does not support two-way syncing between apps right now. Think of Zap workflows as one-directional automations." It is equally honest about the thing most vendors gloss over: "Some apps update by overwriting existing data, while some append to existing data. Zapier recommends you test first to see what your app does." If the tool cannot tell you whether a write replaces or adds, nobody downstream can either.

Vendors who build two opposite one-way pipes and call the result bidirectional have not added arbitration. They have added a second writer.

It gets worse with three systems, and three is the normal number once you have a store, a marketplace and an accounting package. Microsoft, describing the member-wins policy in its own sync service, states the outcome without dressing it up: "If there's more than one member, the final value depends on which member syncs first."

A usable rule of thumb: two-way sync without a conflict log is not two-way sync. It is two one-way syncs racing, and the loser is never told.

Six questions to put in writing

None of these need a developer to answer, and each has a wrong answer you can recognise.

1. "Give me the table of fields with an owner beside each." Address, owner: store. Price, owner: ERP. Stock, owner: warehouse. Not a slogan about a source of truth - a table. If nobody can produce it within the hour, the decision has not been made, and it will get made accidentally at runtime.
2. "Which direction does each field move?" Per field, not per integration. One common connector runs four directions at once depending on the data type. A vendor who answers "bidirectional" and stops has not answered.
3. "Which fields is the sync switched off for?" The good sign is per-field toggles that default to not writing. The merchant who wanted quantity synced and got descriptions overwritten was asking for this and could not get it.
4. "If the value changed after your sync read it, what happens?" Acceptable answers: it fails and retries, it queues for review, it alerts somebody. The common answer, and the one to worry about, is "it writes."
5. "Where are conflicts logged, separately from errors?" A successful sync and a sync that clobbered a newer value are different events. If the only artefact is a green tick, the conflict was already resolved against you.
6. "What compares the two systems on a schedule and tells me where they disagree?" Shopify tells app developers to build exactly this, because delivery is not guaranteed: use reconciliation jobs to periodically re-fetch and stay consistent. Not a dashboard - a report that arrives whether or not anything is wrong.

A cheap seventh: ask for the sync interval in minutes, in writing. "Real-time" is a marketing word. The interval is the width of the window in which your edit can disappear.

The screen that does it right

Shopify shipped conflict detection in its inventory bulk editor in December 2025: when the underlying value changed while you were editing, it shows the old value, the new value, and lets you keep the suggestion, keep yours, or discard.

That is what handling a conflict looks like. It is worth knowing that it exists on one screen, in one product, because it sets the standard for what to ask for and shows how rarely it is offered anywhere else.

The connection to a wider problem is worth naming. A sync that overwrites the right answer produces no error, and the tools around it report success, which puts it in the same family as automations that fail without telling you - except here the fix is not better alerting. It is deciding, in advance and in writing, which system is allowed to write what. That decision belongs in the same document as the rest of what you should get when somebody hands an integration over to you, alongside the handover checklist.

If you would rather have someone map which of your systems is currently allowed to overwrite which, that is what the process audit is for: $299, three business days, and a written account of what to fix first.

Sources

Vendors that name an owner, in their own documentation: Linnworks on being the source of truth, Xero Inventory Plus on overwriting product details, Shopify Marketplace Connect as system of record, and Intuit's connector on overwriting manual stock changes.

The mechanics of a lost update: Shopify on webhook ordering and reconciliation jobs, Shopify's compare-and-set for inventory quantities, QuickBooks Online's version token, Microsoft on conflict resolution with more than two members, and the IETF definition of the lost update problem.

What Zapier says about its own limits: two-way syncing is not supported and overwrite versus append is app-dependent.

Merchant accounts are public posts and reviews: stale numbers between polling intervals, and connector reviews describing overwritten marketplace edits (one, two).