I read two Shopify help pages this week, back to back, and I’d recommend the exercise to anyone running more than one storefront.
The first is the Sidekick page. Sidekick is Shopify’s assistant inside the admin, and it now completes multi-step tasks from one plain-language prompt. Shopify’s words: it “presents changes for your store’s review before applying them”, and for longer tasks it “continues working in the background, even if you close the chat or navigate away, and notifies you when it’s ready for review”. Describe what you want, see the plan, approve it, get on with your day. That is agentic done properly. Agentic = describe the change in plain language; the platform ships it across every property, with approval and audit built in. Shopify has built the first half of that sentence about as well as anyone.
The second page is the one about expansion stores.
On this page:
When Shopify Plus is the right answer
Before the argument, the concession, because it’s real. If you run a single high-volume DTC brand and don’t expect to consolidate other digital properties, Shopify Plus is the right answer, and Sidekick makes it a better one. Review before apply is exactly what I’d want for one store. We’ve said as much in our BigCommerce vs Shopify Plus vs Core dna comparison, and Sidekick strengthens that side of the table.
The question is what happens to that model at the edge of the store.
What 10 stores share, in Shopify’s words
A Plus contract gives an organisation a maximum of 10 stores at no additional cost: one main store and up to 9 expansion stores. Users and billing are managed centrally. On what else the stores share, the documentation is unusually direct: “Store settings, products, collections, and inventory aren’t synced between stores. They don’t share data by default.” Each store “operates completely independently with its own separate data, settings, and configurations.” You can import data from a sibling store at the moment you create it, and then: “After you create the store, you can no longer import data and you must manually manage your store data.”
All of that is on the page. It’s the operating model, and plenty of businesses are fine with it.
Now picture an operator it wasn’t built for. An Australian retailer, hypothetical, with 6 stores on one Plus contract: AU, NZ, US, a wholesale store, an outlet, and a second brand they acquired last year. A team of 3 looks after all of it. The Monday instruction is: “Raise the free-shipping threshold to 150 everywhere except NZ, and change the announcement bar to say so.”
In the AU admin, Sidekick does this beautifully. It drafts the bar, adjusts the shipping profile, shows the changes, waits. The e-commerce lead reads the plan, approves it, and it ships.
Then she opens the US admin.
The prompt’s unit is the store. Hers is the portfolio.
6 admins, 6 prompts, 6 plans, 6 approvals. The work Sidekick removed inside each store comes back between them, and it comes back as the oldest job in multi-store operations: a person acting as the sync layer. She is checking that store 4 got the same wording as store 1, that the outlet didn’t inherit a threshold it shouldn’t have, that NZ was skipped in every place it needed to be skipped and nowhere else.
And the drift starts the day after. An expansion store agrees with the store it was imported from on its first morning, and on no morning after that by design. Every day after that they are managed separately, because Shopify says they must be. An assistant inside each store makes that faster. Each store gets quicker at becoming its own thing.
The Sidekick page says “your store” all the way through, singular, and I think it means it. That is an honest description of where the product lives.
| Inside one store (Sidekick) | Across a portfolio | |
|---|---|---|
| Who reviews | The store’s admin user | Whoever owns that property group, per change type |
| What is reviewed | The changes to this store | One plan listing every property and its exceptions |
| On failure | The task pauses; you see this store | The run stops and completed properties roll back |
| Where the log lives | This store’s activity | One record per change, naming the property |
| Data underneath | This store’s own data | One dataset presented per property |
What an instruction needs to cross a store boundary
If the operator’s unit is the whole portfolio, the instruction has to be scoped to the whole portfolio too, and that takes more than a bigger prompt box. From building this for multi-property operators, the pieces that matter differ in kind:
- One plan across every property before anything runs, with the exceptions shown as a diff. You see NZ keeping its threshold and the other 5 changing, on one screen, before any of them change.
- Approval scoped to who owns what, by property group, role and change type. The wholesale lead approves wholesale, and nobody approves all 6 from one seat because they happen to hold the keys.
- A failure at store 4 stops the run and rolls back stores 1 to 3. You are never half-shipped across a portfolio with a report sitting in your inbox.
- One log line per change that names the property, the person and the time, instead of one activity feed per store that someone stitches together on a Friday.
There’s a precondition under all four. Products, content and settings have to be one dataset presented per property, which is the exact thing expansion stores are described as not being. It is also the thing that makes multi-site management a structure question before it is a tooling question.
The Plus answer, and where it stops
The fair response from a Plus loyalist is that the organisation layer is the portfolio view. Users, billing, a single login across stores. That’s true, and Shopify’s page is precise about its scope: administration is shared, and the data isn’t. The second response is that sync apps exist. They do, they’re billed per store, each one is another thing to keep in step across 6 admins, and none of them is the place the prompt was typed.
Third, and the strongest: most changes only touch one store anyway. I agree. The change that hurts is the one that fans out, and you don’t get to pick in advance which kind Monday’s instruction is going to be.
Two tests you can run this week
First, count how many of last quarter’s changes touched more than one store. If the answer is a handful, stay where you are and enjoy Sidekick. Second, next time someone shows you an AI assistant for commerce, ask to see the plan for all 6 stores before it runs, and ask what happens when store 4 fails. That second test is the one Core dna is built to pass: one dataset, one plan per property, scoped approvals, rollback, one log. The four items above are a description of it.
Shopify gives you 10 stores at no additional cost. What it doesn’t include is one instruction. For most stores that will never matter, and for the operator with 6, it is most of the job.
Frequently asked questions
Does Shopify Plus sync data between stores?
Shopify’s documentation says expansion stores “don’t share data by default” and that settings, products, collections and inventory “aren’t synced between stores”. Users and billing are managed centrally; store data is managed per store.
Can Shopify Sidekick act across multiple stores?
Sidekick works inside a store’s admin and presents changes “for your store’s review”. Shopify’s documentation describes it in the singular throughout, and we found nothing on the page describing a task that spans stores. Check the page for yourself, since it will change.
When is Shopify Plus the right choice?
If you run a single high-volume DTC brand and don’t expect to consolidate other digital properties, Shopify Plus is the right answer, and Sidekick makes it a better one. The boundary matters when one instruction has to land on several properties at once.
See one plan across every property before anything runs.
Summarize with
