Team and roles

Manage → Team. "Invite staff and control what they can do."

The screen has two tabs: Members and Roles.

Inviting somebody

Enter their email and press Invite.

"They must already have an account."

Worth knowing up front: you do not create accounts for other people. They register and verify their own email first — see Create an account — and then you invite that address onto the site.

The member list shows Member, Role, Joined.

Remove member takes them off the site: "They will lose all access immediately."

The four built-in roles

Role	vi
Owner	Chủ sở hữu
Admin	Quản trị viên
Editor	Biên tập viên
Viewer	Người xem

"The default roles that come with every site. These cannot be edited."

The Roles tab carries a Roles & permissions table listing exactly what each role can do, and that table follows "the server's own rules" — meaning it is not a hand-written description that can drift, but a reading of the thing that actually decides.

When you need to know what a specific role can do, read that table rather than guessing.

Custom roles

If the four do not fit, build your own: Create role. "Roles you create with exactly the permissions you choose."

The role editor has two halves:

Content access — each domain has three levels: None · Read · Write. The domains are Products, Orders, Customers, Discounts, Blog, Integrations, Pages, Theme, Media library, Custom code, Webhooks.

Admin access — the site-level permissions: edit settings, delete the site, export content, view and manage members.

Three levels rather than a single tick is worth using: Read lets a bookkeeper look at orders without being able to change anything, and that is usually what you actually want.

Deleting a custom role

You cannot delete a role that is in use: "This role is still assigned to members. Change their role before deleting it."

That is the right guard — without it, those people would lose access silently and nobody would know why.

Roles also bound API keys

This is easy to miss, and it is the most important part of this page:

An API key can never do more than the person who created it, and that is checked per request, not captured when the key was minted.

Which means: a key created by an admin who is later demoted to Viewer loses write access on the next request. You do not have to go revoke keys, and the integration does not have to keep books.

The same holds for installed apps: an app can never do more than the person who installed it. See API keys and Installing an app.

The practical consequence: demoting someone is the fastest way to narrow everything they built — keys, integrations, apps — all at once.

Site members versus organisations

The list here is the membership of one site. If you work for several clients and want to manage people above the level of a single site, that is Organisations — see Organisations.

Note: when you duplicate a site, the team does not come with the copy. It is one of four deliberate exclusions — see Your first store.