Plan multiple Shopify stores by defining what must remain separate and what the team wants to manage together. Map catalogue ownership, staff access, account responsibility and reporting definitions before changing an organisation structure. Use the worksheet below to distinguish administrative grouping from the specific data-sharing and operational arrangements the business actually needs.
Why does the business need separate stores?
Write the intended reason for each store. It could concern a distinct offer, customer journey, brand or operating responsibility. Record what the separation should achieve and which information is deliberately shared. Keep the decision tied to the business’s actual arrangement rather than assuming more stores automatically create a better sales operation.
Identify a responsible owner for each catalogue, public page and fulfilment handover. Ask how a correction becomes visible in the appropriate store and who checks it. Where the same product appears in several stores, define which source supplies its information and how any store-specific differences are approved.
Shopify describes grouping stores into organisations for shared users and central settings. Documentation. Use that documented administrative capability as one part of the design. Ask separately how catalogue changes, customer records and operational reports would be handled in the proposed arrangement. A shared-user setting should not silently become the specification for data synchronisation.
Which organisation arrangement applies?
Creating a Shopify organisation by grouping requires at least two stores. Documentation. The person grouping Shopify stores must own every store being grouped. Documentation. Only the organisation owner can create an organisation and group stores into it. Documentation. Stores billed in Indian Rupees (INR) cannot use the documented Shopify store-grouping route. Documentation. An organisation’s billing currency cannot be changed after it is set. Documentation. Verify both the common store ownership and the intended organisation owner before preparing any move. Record the eligibility evidence against each store rather than treating access to its admin as ownership.
Grouped stores must use the same billing currency. Documentation. Shopify Plus uses expansion stores instead of the documented store-grouping arrangement. Documentation. Establish the actual plan and billing arrangement before describing a grouping route. Keep the intended store structure and the commercial requirements with the account owner so an implementation choice does not depend on an assumed eligibility condition.
Recurring Shopify app charges continue after a store moves organisations unless the charge is cancelled. Documentation. Charges incurred before a store moves remain with the previous organisation’s billing, while later charges belong to the store’s current billing. Documentation. Include installed applications and their responsibilities in the inventory before moving a store. Record which app serves which store and who reviews the resulting billing and access arrangements. A migration plan should account for those relationships alongside the public site.
Prepare a clear before-and-after diagram for the proposed organisation change. Show the stores, account owners and administrative roles. Keep any consequential change subject to the responsible person’s approval and retain the recovery or support route appropriate to the actual account arrangement.
An original store-separation worksheet
Use this practical checklist for a representative pair of stores. Fill it with the actual account and record references, then use it to prepare the permission and reporting checks. It is an original requirements aid rather than an assertion of automatic cross-store behaviour.
| Separation question | Store-level decision | Shared decision to establish |
|---|---|---|
| Public offer | Brand, content and catalogue purpose | Which source supplies common product information? |
| Record identity | Store reference and product/order keys | How are records distinguished in shared work? |
| Staff access | Tasks allowed in the particular store | Which administrative responsibility spans stores? |
| Ownership | Store owner and recovery route | Who owns the organisation arrangement? |
| Grouping prerequisites | Common owner, plan and billing currency | Two-store creation minimum and organisation owner confirmed? |
| Applications | Installed apps and purpose | Which charges continue and who owns pre-/post-move billing? |
| Reporting | Metric, period and currency definition | How will any combined view be interpreted? |
| Change handover | Approver and store-specific verification | Who confirms the shared change remains appropriate? |
Add an exception for the colleague who needs one store but not the other. That scenario helps the team evaluate whether the intended separation is reflected in access decisions. Include a similar product or order reference in both stores so a shared report or integration must identify the source explicitly.
Keep the catalogue mapping readable. If a common product has different public descriptions or availability treatment, record which differences are intended. Ask how the responsible person identifies and corrects an accidental discrepancy without overwriting an approved store-specific variation.
How should staff permissions be reviewed?
When a store is grouped into a new organisation, users retain store permissions but lose their organisation permissions. Documentation. Grouping moves the specified billing-email and payment-method Finance permissions to organisation Billing permissions and removes them from users except the organisation owner. Documentation. Shopify organisation Billing permissions apply to all stores in that organisation. Documentation. User management permissions become organisation-level permissions after grouping. Documentation. In the permission register, identify the affected billing-email and payment-method tasks by their actual labels, then record who should receive the required organisation role. Restore only approved access and test an out-of-scope task as well as an allowed one.
Shopify instructs users to review staff permissions after grouping stores. Documentation. Shopify-managed roles cannot be customised or deleted. Documentation. Compare the intended task map with the actual role assigned to each representative user. Give the reviewer a reason for each elevated responsibility and a way to identify access that belongs only to one store.
Each Shopify store has one store owner and each organisation one organisation owner. Documentation. Owner roles change through ownership transfer rather than ordinary role assignment. Documentation. Record the accountable owner and the route for a future authorised ownership change. Keep that responsibility distinct from giving an employee an administrative role for day-to-day work. A handover should leave the organisation able to identify who controls the relevant account relationship.
The Shopify App developer role does not grant access to manage installed apps. Documentation. The Store user administrator role cannot manage products or orders. Documentation. Read the role description before using its name as shorthand for a capability. Include actual permitted and denied tasks in the proposed acceptance exercise. That gives the team evidence about the intended role boundary rather than relying on a reassuring label.
How should a combined report be defined?
Start from the question the report is meant to answer. Record the contributing store, metric definition, date basis, currency and filter for each source. Decide how cancellations, refunds and other adjustments should appear in the chosen comparison using the relevant report documentation.
Retain the source-store identity when assembling a shared view. Ask the reporting owner to trace a representative result back to its original store and record. Where definitions differ, keep the difference visible rather than presenting a combined total with an ambiguous label.
Specify any proposed cross-store report or integration separately from the organisation settings. Ask for the actual data route, access arrangement and update process. The acceptance record should show which functionality was demonstrated and which remains a requirement to implement.
Hypothetical example: one colleague receives wider access than intended
Imagine a colleague is meant to maintain product information in one store while only reading a report from another. A proposed organisation change alters their administrative position. This hypothetical case tests the permission review before the new arrangement becomes ordinary practice.
Before the rehearsal, record each store’s owner, plan and billing currency, and the proposed organisation owner. Stop the grouping proposal if a documented prerequisite is unmet. Compare the permission register before and after a controlled demonstration: identify removed organisation access, retained store access and any approved billing or user-management role that needs reassignment. Record the store’s continuing app charges and the billing owner on each side of the proposed move date. Then ask the demonstrator to show the intended tasks using a representative test role. Include an operation outside the intended scope. Compare the actual results with the task map, then assign any mismatch to an owner before acceptance.
Next, trace a similar order reference from both stores through the proposed reporting view. Check whether the source remains unambiguous. This combines access and record-separation questions without assuming that a common organisation supplies every required reporting function.
For wider platform constraints, see Shopify in Zambia. Discuss the store and integration brief through online stores and web development. Get started with the stores, roles and sharing boundaries you need to assess.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.