Roles

Composing a role

A role has a key, a display name and the permissions you tick from a list grouped by area: content, models, files, operations, settings, integrations and notifications. Permissions are specific: publishing content is one, and changing a model is another. The key cannot change once the role exists. A role you no longer want is disabled, and roles are never deleted.

Two ready-made roles

Workspace administrator covers everything in the workspace, including billing, projects, invitations and export. Project administrator covers everything inside a project. Enforcement reads permissions and never a role's name, so a role you compose is enforced exactly as a ready-made one is.

Where a grant applies

You grant a role across the whole workspace or on one project. Grants add up, and one person can hold several roles. People join your team by invitation, and every invitation carries a role. A change to someone's role takes effect at their next session refresh.

You grant only what you hold

Every permission in a role you grant must be one you already hold. A workspace always keeps at least one workspace-wide administrator, and a revoke that would leave none is refused.

Roles for your users

The people who sign in to your application hold roles too. You declare them per project in your config file or with foir customer-roles in the CLI (the docs call your users "customers"). Their permissions are scopes, such as running one named operation or writing one model.

A role marked as the default applies to every user with no assignment, and a user with no role holds a read-only token. A changed role reaches a signed-in user at their next token refresh, with no need to sign in again. In a project with organisations, a user holds a role in each organisation through a membership.