Multi-store overview

If you sell the same products from more than one Shopify store — a domestic store and an EU store, a wholesale store alongside retail, a marketplace-facing store — multi-store keeps their stock in step. Sell a product in one store and every other store that carries it drops by the same amount, automatically.

The mental model

Everything follows from one decision you make at setup:

One store is the main store. Every other store is a partner.

1. The main store holds the recipes. Your bills of materialsBill of MaterialsA bill of materials tells Assemblified how to build one unit of a finished good. When a customer orders the finished-good variant, Assemblified deducts the right component quantities from inventory automatically. Read more → and sub-assemblies live there, and only there. When a partner store sells a product that is built from components, the main store is what runs the build and deducts the components.

2. The main store defines the locations. A main-store location is a slot, and every partner location you want to participate is mapped onto one of those slots. See Mapping locations.

3. The main store wins every disagreement. When the stores’ numbers differ and we cannot account for the difference from our own records, the main store’s number is the one that stands. See How corrections work.

4. Partners follow. A partner store sells, restocks and fulfils normally. What it does not do is manage the shared products’ recipes or restock them locally — that belongs to the main store. See What syncs, and what partners can’t do.

Which store should be the main store?

The one where your inventory really lives, and where you already do your production planning. If one store is clearly your operational home, that is the main store. If you are genuinely symmetric, pick the one with the most complete product catalogue — the main store’s catalogue is what defines the shared SKU list.

What a group is

A group is one main store plus its partner stores. A store belongs to at most one group. There is no way to have a store participate in two groups at once, and no way to nest groups.

To create one, from the store you want as main: Settings → Multi-store → Create group. The group gets a group code (grp_…) which the Group tab shows with a copy button.

Linking a partner takes both stores:

1. At the main store: Settings → Multi-store → Group → Invite a store, entering the partner’s *.myshopify.com domain.
2. Copy the group code and send it to whoever administers the partner store. Inviting alone shows the partner nothing — the code is what lets them find the invitation.
3. At the partner store: Settings → Multi-store → Have an invitation? → paste the code → Check invitation → Accept invitation.

Plan requirements:

• creating a group requires the Enhanced plan on the main store;
• a partner store can accept an invitation on any plan.

What happens if an Enhanced plan lapses

Plans are re-checked whenever Shopify tells us a store’s subscription changed, and the group reacts:

• the main store drops below Enhanced → the whole group is paused. Nothing syncs anywhere. It resumes by itself when the plan comes back.
• a partner drops below Enhanced → that store alone is paused. The rest of the group keeps syncing, and changes bound for the paused store are held (Ledger: “Waiting for the store to resume”) until its plan returns.

Caution

A store with “Disable inventory reduction” switched on cannot join a group. Multi-store exists to move stock; a store that has opted out of moving stock has nothing to contribute.

How products are matched across stores

There is no list you have to maintain up front. Matching happens two ways, and both fill the same shared-SKU table:

• From traffic. The first time a product sells anywhere in the group, we look for the same SKU at each other store, verify it, and remember what we found. From then on it is matched.
• From an index build. Settings → Multi-store → Sync runs → Build index walks every store’s catalogue in one pass and matches everything it can. Run this after you first link stores, and again after a big catalogue change.

By default a product is matched by having the same SKU at both stores. If your stores spell a SKU differently, you can override the partner’s spelling by hand in the Shared SKUs tab — a SKU you set by hand is never overwritten by an index build.

An index build only ever adds. It never removes a link and never marks one stale; removing an entry is a deliberate act on the Shared SKUs tab.

Each store’s entry shows one of:

Badge	Meaning
Matched	verified present at that store. This one syncs.
Not checked	we have not looked yet. The next sale for it will check.
Not found	verified not present at that store. We re-check every 24 hours.
Gone	it used to be there and the product was deleted. We re-check on the next sale.
Ambiguous	either the SKU sits on more than one product at that store, or a partner store has its own bill of materials for it.

Ambiguous means we look but never write

While a product is ambiguous we keep checking it every 24 hours — so it heals by itself once you fix the catalogue — but we never change its stock. That is deliberate: a SKU that is a recipe at two stores would otherwise have its components consumed twice for one sale.

The intended setup is: the main store carries the bills of materials, partners don’t. If a partner has its own local BOM for a shared SKU, delete it. (A recipe for a shared SKU at the main store is normal and is not a conflict — that is the whole design.)

The Shared SKUs tab is built for a catalogue-sized table: the state counters along the top are clickable filters, the search box matches the main store’s spelling and every store’s own spelling across the whole index (not just the page you are on), and the per-row actions — set a store’s SKU, re-check, remove — appear when you hover a row.

The full picture, once

                  ┌─────────────────┐
       sells ──►  │   MAIN STORE    │  ──► holds the recipes
                  │                 │      defines the locations
                  │                 │      wins disagreements
                  └────────┬────────┘
                           │  every change, both directions
              ┌────────────┼────────────┐
              ▼            ▼            ▼
        ┌──────────┐ ┌──────────┐ ┌──────────┐
        │ PARTNER  │ │ PARTNER  │ │ PARTNER  │
        └──────────┘ └──────────┘ └──────────┘
              ▲
        sells here too — the change travels to the main store
        and on to every other partner

A sale at any store propagates to every other store. It is not one-way. What is one-way is corrections: when we cannot reconcile a difference, the main store’s number is the one that survives.

What you’ll see in the app

Settings → Multi-store is five tabs. Each one is addressable by URL, so a link to a specific tab survives a reload and can be sent to someone else.

Tab	Shows
Group	who is in the group, each store’s role and state, the group code, invitations, pause/resume, leave/disband
Locations	the slot map — which partner location stands for which main location
Shared SKUs	the matched-product table, with each store’s state and its own spelling
Sync runs	index build, settle and the hourly check — with progress, failures, the worksheet, and the Corrections table underneath
Ledger	every change we received and every change we sent, with its outcome

The Ledger is the one to reach for when you ask “did that actually sync?”. Every row says what we sent, where, and what came back — including the exact reason when we sent nothing.

Corrections — every stock level a run wrote or explained — is not a tab of its own. It sits at the bottom of the Sync runs tab, because what it lists is the outcome of the runs above it.

Before the first sync

Multi-store starts in record-only mode: it watches, writes down what it would have done, and changes nothing. Use that window.

1. Link the stores and accept the invitations.
2. Map the locations. Nothing syncs from an unmapped location — see Mapping locations.
3. Build the index (Sync runs → Build index) so the Shared SKUs table is populated.
4. Watch the Ledger for a day while the group is still recording only. Every row will say what would have happened. Look for rows saying “Location not mapped” or “No matching SKU” — those are your setup gaps.
5. Settle, so every store starts from the same numbers — see Settling stock.

Going live is not a switch in the app

There is no on/off toggle for syncing on the Multi-store page today. A group is created in record-only mode and Assemblified switches it to live syncing for you — ask support when your setup checks out. The page tells you which mode you are in: a blue “Observe mode” banner on the Group tab and a “Recording only” badge on the Ledger while it is recording, a green “Syncing is on” banner and a “Syncing” badge once it is live.

What you can do yourself, at any time, is Pause group on the Group tab of the main store. That stops everything for every store at once, and resuming does not replay what happened in between.

Settle before the first hourly check

Once syncing is live, the hourly check imposes the main store’s numbers on every matched product — whether or not you have settled. If a partner’s counts are the correct ones, settle first, choosing the values you want. Settling afterwards is more work.

Retention

We keep the whole ledger. There is no automatic clean-up, so “what happened to this SKU three months ago” stays answerable.

Related

• What syncs, and what partners can’t do
• How corrections work
• Mapping locations
• Settling stock and the worksheet