Users & Roles

CMS access is controlled by a role stored on each user. Roles form a strict hierarchy: each role can do everything the roles below it can.

Role	Can do
owner	Everything an Admin can, and cannot be demoted, disabled or deleted by anyone else. Can transfer ownership.
admin	Structure (content types, forms), users and roles, settings, webhooks, cache purge and the audit log, plus everything below.
editor	Any entry, form-submission triage, media, pages and templates, content-type and form field management, sending email.
author	Create entries; edit and delete only entries they created. Read access is unrestricted.
viewer	Read-only across the admin.
none	A website or application account with no CMS access. The default for every new account.

none is not a CMS role. It is what a visitor who registers on your website, or a Commerce customer, has. A none account can never reach the admin API.

The Owner

• A fresh deployment has no users. The Owner is created once through the bootstrap.
• The Owner is hidden from other users: it does not appear in the Users list or audit log for anyone else, and looking up or changing the Owner as a non-Owner returns 404.
• Ownership moves only through the transfer flow (Profile → Security, visible to the Owner), which needs your password re-entered. It swaps roles: the current Owner becomes Admin as the target becomes Owner.
• A change is rejected if it would leave the deployment with no Owner and no Admin.

Manage users

Admins and above open Users:

• Add user creates an account with the Editor role and a one-time temporary password. The password is shown to you once and also sent to the person in an onboarding email. The person must verify their email before they can sign in. Change the role afterwards if Editor is not what you want.
• Change a role from the table’s inline select. Granting a CMS role to an account that currently has none (a website or Commerce account) asks for confirmation first, since that’s a deliberate access grant, not a routine role adjustment.
• Click a row to open that user’s detail page: account type, role, phone, join/last-active dates, session management, disabling, and (for accounts eligible for it) the Developer tools toggle. Developer tools is granted per-user from here rather than from the table, since it’s not something you want to flip by accident in a dense list — see Settings for the deployment-wide flag it depends on.
• Disable an account (which signs it out everywhere) or delete it, from the detail page. Disabling an Admin needs your password re-entered.
• Internal notes: free-text, staff-only, visible on the detail page — useful for context a client-facing profile field shouldn’t carry.

Every role change, disable and ownership transfer is written to the audit log; the Audit log page (Admins and above) shows each entry with a readable before → after diff rather than a raw JSON dump.

Account types

The Users list classifies every account as one of three types, shown as a filterable column:

• CMS Staff — has a role above none.
• Commerce Customer — a none account with real engagement: at least one order, a saved address, or a saved profile field. A customer row created by an edit that never went further (for example an abandoned profile edit with no purchase) does not count.
• Website User — a none account with no engagement yet.

This keeps the CMS’s own idea of “customer” consistent with Commerce’s storefront listings, which use the same engagement definition.

Roles and website accounts

Website registration never grants a CMS role. Only trusted server-side code assigns one: the bootstrap, Add user, and the role-change and ownership routes. The client cannot set a role. See Authentication.