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 assembly billsSub-assemblyA reusable assembly block that composes into bigger bills: define it once, include it in any bill of materials, and Assemblified expands it into its own components at execution time. The app now calls it an assembly bill. Read more → (also called 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. On the Stores in this group card, type the partner’s *.myshopify.com domain into the Invite a store field, then press Send invitation.
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 Elevate plan — the tier above Enhanced — on the main store. The Create group button is visibly and functionally disabled without it, and names the tier;
• a partner store can accept an invitation on any plan.

What happens if a plan lapses

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

• the main store loses the Elevate plan → the whole group is paused. Nothing syncs anywhere. It resumes by itself when the plan comes back.
• a partner loses its subscription entirely → that store alone is parked. The requirement for a partner is not a tier: any active plan keeps it in the group. The rest of the group keeps syncing, and changes bound for the parked store are held (Ledger: “Waiting for the store to resume”) until it is subscribed again.

Caution

A store with “Disable inventory reduction” switched on (Settings → Integrations) cannot join a group. Multi-store exists to move stock; a store that has opted out of moving stock has nothing to contribute. The refusal says exactly that, and names the setting to change.

Multi-store is still labelled beta in the app

The Multi-store page carries a beta notice with a link to support and to these docs. Everything described here is self-serve — you do not need support to create a group, link stores or switch syncing on — but the notice is there because a mistake in this area moves real stock in several stores at once. If your setup is unusual, the offer to have someone look at it before you go live is a real one.

How products are matched across stores

There is no list you have to maintain up front. Matching happens three ways, and all three 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 hand. Type a main-store SKU into the Add a SKU field on the Shared SKUs toolbar and press Add. This is the one way to seed a link the other two cannot: a product whose SKU string differs between stores has nothing for an index build to match on, so you add the main store’s spelling here and then set each store’s own spelling on the row.

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. The pencil (or +) beside a store’s cell is what opens that editor, and it works even for a store that has no entry on the row yet, which is exactly the case for a store invited after the link was created.

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. Every control sits in the table’s own toolbar: the search box (which matches the main store’s spelling and every store’s own spelling across the whole index, not just the page you are on), the state counters, which double as clickable filters — press the active one again to clear it — and, at the main store, the Add a SKU field with its Add button. The per-row actions, Check again and Remove, appear when you hover a row. A partner store sees the same table and the same filters, with nothing to press: only the main store changes the index.

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	two tabs of its own: Runs (index build, settle and the hourly check, with progress, failures and the worksheet) and Corrections
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 the second tab inside Sync runs, beside Runs. It lives there because what it lists is the outcome of the runs on the other tab.

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.
6. Turn syncing on, below.

Turning syncing on, and off again

Going live is a switch you own. On the Group tab at the main store, under the mode banner, there is a Syncing control:

1. Turn syncing on. Press it and a confirmation appears: “Start syncing inventory to your partner stores?” From that point the inventory changes on the Ledger tab are applied to your partner stores as real stock, within seconds — and what happened while the group was only observing is not replayed. Only new events sync. Confirm, and the banner turns green.

2. Turn syncing off at any time, from the same place. There is no confirmation, because stopping breaks nothing. New changes stop being sent immediately; changes already on their way still land.

The button is main-store only. A partner store sees the mode banner and the badges, but not the switch.

Which mode am I in?

Two places say so, and they always agree:

• the Group tab carries a blue “Observe mode” banner while the group is recording only, and a green “Syncing is on” banner once it is live;
• the Ledger tab carries a badge reading “Recording only: nothing is written to any store” or “Syncing: inventory is written to partner stores”, and its first tab is titled “Would-be inventory changes” while recording and “Inventory changes” once syncing.

A paused group is not live whatever the sync switch says. Pausing and syncing are two independent controls: syncing off means “stop sending”; paused means “stop everything”.

Turning syncing off is the lighter alternative to pausing

Both stop stock moving between stores, and neither replays the gap afterwards. The difference is reach:

• Syncing off stops outbound writes and stops the hourly check. The group keeps recording, so the Ledger keeps filling with what would have happened, and you can read it. Invitations, the index and the location map all keep working.
• Pause group stops the group. Orders are still logged as history, but nothing is routed anywhere, the hourly check does not run, and the group cannot accept new members until it is resumed.

If you want the stores to hold still while you investigate something, syncing off is usually enough — and it leaves you with the diagnostic trail that pausing thins out. Both are on the Group tab of the main store; see Record-only mode, and stopping the group.

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