Organisations
Group the people who run several stores together — and the thing that matters most: joining one grants access to NO store by itself.
Organizations, at /orgs.
"A team that runs stores together. Adding someone here opens no store — store owners grant that in their own settings."
That second sentence is the whole model, and it runs against most people's intuition. Reading it properly saves you a confused afternoon.
Four steps, in this order
The screen itself lists them:
1. Create the organisation and name your team. Whoever creates it is the owner.
2. Invite colleagues by email. The invitation appears in their notification bell and must be accepted. "An invitation opens no store."
3. A store owner goes to that store's Settings → Agency, picks the organisation and presses Grant. "That is the only step that opens access."
4. After step 3, every member can see and work on that store — including people added later.
Step 3 is the one that gets skipped. People create the organisation, invite the whole team, then wonder why nobody can see any stores. Because no store has been granted to the organisation.
Why it is two steps
An organisation answers "who is on my team". Granting answers "which stores may that team run".
Merge them and adding somebody to the team would open every client store to them — with the store owner having no say. Kept apart, the store owner keeps the decision, and the agency can still manage its own staffing without asking permission every time it hires.
Three roles in an organisation
| Role | vi |
|---|---|
| Owner | Chủ sở hữu |
| Admin | Quản trị |
| Member | Thành viên |
"Members can reach every store granted to this organisation — and no other."
That is a clean boundary: an organisation's reach is exactly the list of stores granted to it, and nothing more.
Pending invitations
The Invited, not yet answered area shows people invited but not yet joined: "They are not in the organisation until they accept."
You can Withdraw an unanswered invitation at any time.
Removing someone
Remove a member: "{email} will lose access to every store this organisation runs."
This is the model's strongest point: removing somebody from the organisation cuts their access across all client stores at once. No walking site by site.
Leaving
Leave organisation — "You will lose access to every store {org} runs. Somebody still in it has to invite you back."
There is no way back on your own. Make sure somebody else is still in it before you leave.
Transferring ownership
Transfer ownership hands the owner role to another member. "The new owner manages members. You stay on as an admin."
You are not pushed out — you step down one level.
Deleting an organisation
Delete organisation removes it and all its members, and cannot be undone.
But there is a guard:
"Release the {n} stores this organisation runs before deleting it."
You cannot delete an organisation that is running other people's stores. You have to Release each store first — otherwise those stores would lose their operator without their owners knowing.
Stores this organisation runs
The Stores this organisation runs area lists them, each with Open and Release.
Release is the agency's side of ending an engagement. The store owner can do the equivalent from their side — see Moving sites around.
Organisations versus a site's team
Do not confuse the two lists:
- Organizations (
/orgs) — your team, spanning many stores. - Team (
Manage → Team) — the members of one store. See Team and roles.
A store can have both at once: the owner's own staff, plus an agency granted operational access.
Apps belong to organisations too
If you build apps, an app is published by an organisation rather than by a person. With no organisation, the developer portal says so immediately: "Apps belong to an organisation." See Build an app.
Updated 22/08/2026