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 flow execution	yes	materials and the finished-good quantities the flow sets
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 (multi-location mode) 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”
Running a flow that touches a shared product	the whole run is refused, listing the blocked products
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. Flows and build runs are the opposite — they are 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 flow 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 views behind one switch, plus filters that run over the whole ledger rather than the page you are looking at:

View	Shows
Inventory changes (default)	one row per change to one store: store, location, SKU, the change, its status and its reason
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. 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.

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. Switching a group to live syncing is not a control on this page — see the overview.

What you can stop yourself is the group: Settings → Multi-store → Group → Pause group, at the main store. While it is paused, orders are still written into the Ledger as history but produce no stock changes anywhere, and the hourly check does not run. Resuming does not replay the gap — 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: that only happens when a partner’s Enhanced plan lapses, and it holds that store’s changes as “Waiting for the store to resume” rather than dropping them.