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 a webbuilder account."

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

The member list shows Member, Role, Joined. Somebody who came in through an organisation is marked "through {org}" — see Organisations. The search box above the list filters by email, role or organisation name; typing somebody's email into the ⌘K box lands you on their row here too.

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

"Preset roles that ship with every site. These can't be changed."

The Roles tab carries a Roles & permissions table listing exactly what each role can do — "from the server's rules", meaning not a hand-written description that can drift, but a reading of the thing that actually decides. When you need to know what a role can do, read that table rather than guessing.

Custom roles

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

The role editor has two halves:

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

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

Three levels rather than a single tick is worth using: View 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. Reassign them before deleting it."

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

Roles also bound API keys

Easy to miss, and 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.

When you duplicate a site, the team does not come with the copy — one of four deliberate exclusions, see Your first store.