What syncs, and what partners can't do

What travels between stores

Anything that moves stock through Assemblified and is a matched product travels to every other store in the group.

Change	Travels?	Notes
A sale of a matched product	yes	including sales of a BOM’s components at other stores
An order edit, cancellation or refund	yes	as the difference from what we last recorded, so a quantity change of +1 sends +1, not the whole line again
Component consumption from a BOM build	yes	when the main store builds a product, the components it consumes are broadcast
A restock or stock count of a material in Assemblified	yes	done at the main store — see the partner section below
A transfer, purchase-order receipt, stock take or adjustment from Logistified	yes	only from the main store; a group runs one Logistified instance
A work order completing or being reversed	yes	the finished good it produced and the components it drew
A build run — building a bill of materials on the spot, or a work order’s build run	yes	the materials it consumed and the finished-good quantity it produced
A recalculated buildable count from dynamic adjustment	yes	broadcast from the main store only, as an absolute value (“this is now exactly N here”), never as a difference. A partner’s own recalculation is deliberately silent

What does not travel

Change	Why not
A stock edit made directly in Shopify admin	we only broadcast changes that go through Assemblified. A direct Shopify edit is invisible to us at the moment you make it — but the hourly check will find it, and the main store’s value is what survives. See How corrections work
Anything on a product that is not matched	no match, nothing to send it to. Fix it on the Shared SKUs tab or by running an index build
Anything at a location that is not mapped	see Mapping locations. We never guess a location
Anything on a product that is ambiguous	a SKU that is also a recipe at the partner store would be double-consumed. We check it but never write
Prices, product titles, descriptions, images, metafields	multi-store is about stock. It changes nothing else
Orders, customers, fulfilments	these stay entirely within the store they belong to
Bills of materials themselves	recipes live at the main store. They are not copied to partners

Sales at a partner store

They work exactly like sales at the main store, with one addition: if the product is built from components, the main store runs the build.

The partner’s own finished-good stock drops at the partner. The order details travel to the main store, which expands the recipe, consumes the components from its own inventory, and broadcasts those component changes to everyone else. So a partner store can sell a manufactured product without holding the recipe or the raw materials.

Two consequences worth knowing:

Timing follows your main store’s settings. If the main store deducts components at fulfilment — which is what Multi-location sensitive adjustments does, under Settings → General — rather than at checkout, a partner’s order behaves the same way: the build waits for the fulfilment signal. That can legitimately be days.
The order shows up in the main store’s execution log under a composite id that names the partner store, and its link opens the order in the partner’s admin, not the main store’s.

What a partner store is blocked from doing

On shared products — products the shared-SKU index has confirmed as Matched at that store — a partner store is blocked from four operations. Each refusal names the specific products.

Operation	What you’ll see
Restock / stock count in the raw-materials spreadsheet	shared rows are skipped and reported; the rest of your submission goes through
Adjusting pre-assembled stock for a shared finished good — from the BOM page, from a safety-stock release, or through the API	refused outright. It is one product at one location, so there is no “rest of the submission”
Building a bill of materials on the spot when it touches a shared product	the whole run is refused. The dialog shows a red banner naming the blocked products, not counting them
Starting a work-order build run that touches a shared product	the whole run is refused, listing the blocked products

Three details that come up:

Restocks are partial, not all-or-nothing. If you submit twenty rows and three are shared, the seventeen go through and the three are reported back as skipped. Only a submission where everything is shared is refused outright. Build runs are the opposite — a build is one physical act, so half of one is not a smaller version of it.
Blocking is by product, not by category. A partner’s own products — anything not confirmed Matched in the shared-SKU index — behave completely normally. A SKU still sitting at “Not checked”, “Not found”, “Gone” or “Ambiguous” is not blocked.
A refused build still leaves a log entry, marked failed, naming the blocked products. A run that vanished without trace would be indistinguishable from one nobody started.

Reading the Ledger

The Ledger tab is the record of everything. It holds three tabs, each carrying a count, plus filters that run over the whole ledger rather than the page you are looking at:

Tab	Shows
Inventory changes (default)	one row per change to one store: store, location, SKU, the change, its status and its reason. While the group is only recording, this tab is titled “Would-be inventory changes”
Events	the order events the group received, newest first
Index coverage per store	how many SKUs each store has in each state

Narrow it with the store picker, the SKU search, and — once syncing is live — by clicking a status counter, which doubles as a filter. While the group is still recording only there are two summary badges instead, “Ready to sync” and “Skipped”, because a would-be change has no delivery status to count. The SKU and status filters apply to inventory changes only: an event row carries neither, and the tab says so rather than letting an empty table imply otherwise.

A row can be expanded for its Details: what Shopify said, the resulting stock level, the order position and the message id.

Each inventory-change row carries a Status and, when something stopped it, a Reason.

The statuses:

Status	Means
Recorded	record-only mode. This is what we would have sent
Queued / Sending	on its way. Clears in seconds
Applied	done, and we recorded the resulting stock level
Waiting for location	waiting for Shopify to tell us where the order ships from
Waiting for fulfilment	the main store consumes components at fulfilment. Can sit for days — this is not stuck
Waiting for the store to resume	that store is paused. Held, not lost — it is sent when the store resumes
Sent for building	the order reached the main store, which is running the recipe
Not found / Ambiguous / Item deleted	the shared-SKU index’s verdict for that store
Failed	Shopify refused it. The exact message is shown
Skipped	see the reason beside it

The reasons you will meet most:

Reason	Means
Location not mapped	the change happened at a location that store has no counterpart for. Fix the map
Location not known yet	Shopify has not told us where the order ships from
Not found at that store	the product does not exist there. We re-check every 24 hours
Ambiguous: that SKU is a bill of materials there	remove the partner’s local recipe, or fix the duplicate SKU
Superseded by a newer change	a later change already covers it. Nothing to do
Nets to zero: nothing to send	the change cancelled itself out
Would sync	record-only mode: nothing was wrong, we simply did not write

An Applied badge with an empty reason is the healthy row. Every other outcome tells you something specific, and none of them is “we don’t know”.

Record-only mode, and stopping the group

A new group records only: the ledger fills with rows saying what would have happened, and nothing is written to any store. You switch it to live syncing yourself, on the Group tab at the main store: press Turn syncing on and confirm. The confirmation is there because the first thing that happens afterwards is real stock moving in your other stores, and because the observe window is not replayed — only new events sync. See Turning syncing on, and off again.

There are then two ways to stop, and they are not the same size:

Turn syncing off (same button, same place, no confirmation). New changes stop being sent immediately, and the hourly check stops running too. What does not stop is the recording: the Ledger keeps filling with what would have happened, so you keep the diagnostic trail. Changes already on their way still land.
Pause group (Settings → Multi-store → Group, at the main store). This stops the group. Orders are still written into the Ledger as history — marked “No change” — but nothing is routed anywhere, the hourly check does not run, and the group cannot accept new members until it is resumed.

Neither replays the gap when you switch it back on; nothing was queued up to replay. Use the hourly check or a settle to bring the stores back in line afterwards.

Pausing one store is different again: that happens when a partner store loses its subscription entirely, and it holds that store’s changes as “Waiting for the store to resume” rather than dropping them.