Administration

Roles & permissions

The four roles, the permission matrix, customizing role permissions, and how capability gating interacts.

The four roles

Every member has exactly one role; site scope narrows where it applies.

The permission matrix

Settings → Roles shows the full matrix: every permission (grouped by area — items, stock, counting, purchasing, users, settings, and so on) against every role.

With the custom-roles plan capability, the matrix is editable: tighten or extend a role's permissions to fit your operation — an operator role that can also manage labels, an admin without cost visibility (the view-cost/edit-cost permissions are separate for exactly this). Reset to default returns a role to the stock definition. Changes apply to everyone holding the role from their next request — nobody has to sign in again — and are recorded in the audit log.

Guardrails

Managing users does not make an Admin an Owner:

• Only an Owner can grant, invite, or remove the Owner role, or change an Owner's role or status.
• Nobody can change their own role or edit the permissions of a role they hold.
• The organization always keeps at least one active Owner.
• The Owner role always has every permission and cannot be edited, and a matrix edit cannot grant a permission the editor does not have.

Permissions vs plan capabilities

Two independent gates decide what someone sees: permissions (role — may this person do it?) and plan capabilities (subscription — does the organization have the feature?). A locked feature stays locked for every role until the plan includes it; a permission missing from your role hides the action even on the best plan. When someone "can't see" something, check both.