Skip to main content

Who owns your product data

One rule decides how nearly everything on a channel behaves:

Yessort owns the data. The channel is told, not asked.

Stock figures travel outwards only. Product records are Yessort's to change. The store is a display surface that gets instructed, not a second system that Yessort negotiates with.

This matters most when the two disagree. If the stock on your Shopify store is wrong in normal running, Yessort does not accept the store's figure and adjust itself — it pushes the correct figure back out. Recovering from an outage works the same way: Yessort re-sends what it holds, rather than reading in what the store did while it was gone.

The two exceptions​

The rule has exactly two exceptions. Both are narrow and deliberate.

Onboarding. When you first connect a store, its products and stock are the only sensible starting point — Yessort has nothing yet. So the connection process pulls the store's catalogue in and uses it to seed Yessort, under your review. This is the one window in which the store's data is trusted. It closes when you activate the channel. See how channel onboarding works.

A small stock difference on a brand-new link. When the review queue links a listing for the first time, Yessort compares the store's on-hand figure against its own for that site. A difference within 20% of the store's figure, or five units, whichever is larger is booked automatically. Anything larger is held for you to decide on.

That automatic booking exists for a specific reason: a variant that has just been created in Yessort sits at zero, and the next availability push would send that zero out and wipe the stock the store was correctly showing.

The reconcile that runs when a channel is activated with listings already linked behaves differently — it books nothing at all, and holds every difference for a person. A store's reported on-hand includes units committed to open orders, so booking those differences at a live cutover once created over a thousand units of stock that did not exist. Both cases are covered in keeping stock in step.

What the store is allowed to change​

Yessort subscribes to the store's product events — it is told when a product is created, updated or deleted there. Subscribing is not the same as obeying. What Yessort does with those events is controlled per channel, and the defaults are deliberately cautious.

New products the store knows about and Yessort does not are staged into the channel review queue rather than created. This is on by default. The store proposes; a person decides. Turn it off for a store that sits downstream of another system and should never propose anything.

Edits to products already linked are ignored by default. Yessort stays the sole authority on a linked variant's SKU, barcode, price, name, description and variant title. Each of those can be opened up individually if you want the store to be the place someone edits them, but you have to choose it, per channel and per field.

One thing is not gated: when a newly linked product has no image in Yessort, the store's image is copied across. That copy only ever fills an empty field and never replaces an existing one, so it carries none of the overwrite risk the other settings guard against.

Every setting, with its default and what it governs, is in inbound and outbound settings.

Where the store's word is final​

Two things genuinely belong to the store, and Yessort follows them rather than the other way round.

Whether a product is on sale there. If someone archives a product in Shopify, it comes off sale in Yessort for that channel. If they make it active again, it goes back on. See unlisting and relisting.

What the store reports about an order. Payment status, and the order's own number, are the store's to state. Yessort records them.

Why a conflict is skipped rather than resolved​

If the store sends an edit carrying a SKU or barcode that already belongs to a different Yessort variant, Yessort does not apply it. The write is skipped and the clash is recorded for you to resolve.

There is no option to apply it anyway. Letting the most recent edit win would silently move an identifier off the variant that legitimately holds it, and identifiers are how Yessort matches stock and orders. See resolve a SKU or barcode conflict.