Roles and permissions come from Auth → Roles and travel in the session token. Rules read them from $auth.roles and $auth.permissions.

​
Admin only

Choose Users with role admin in the rule picker.

​
Any of several roles

  • Has role editor, admin

​
By permission

Give roles permissions, then check the permission: Choose Users with permission posts.write in the rule picker. with roles such as editor granted posts.write. Add a new role later without touching any rule.

​
All of several permissions

  • Has permission billing.read, billing.export

​
Roles or ownership

Admins override ownership:
  • Any of these rules pass:
    • Has role admin
    • Owns the record (field) owner_id

​
Staff with a second factor

Choose All of: Users with role staff; Signed in with 2FA in the rule picker. All entries must pass. A staff member who signed in with just a password is refused until they complete the second step.

​
A hierarchy

Roles are not ordered by themselves. For “manager or above”, list them:
  • Has role manager, director, admin
or grant lower permissions to higher roles and check the permission. The second scales better.

​
Read-only role

A viewer who can list and get but never write:

​
Roles that depend on the organization

A person may be an admin in one organization and a member in another. Use the organization role, not the global one:
  • All of these rules pass:
    • Compare values: $record.org equals $auth.org
    • Compare values: $auth.org_role is one of admin, owner

​
Service-only operations

For things only your servers do: Choose Secret keys & Studio in the rule picker. Reads and writes then work only with a secret key. Offer users what they need through a route.

​
Show UI by role, protect by rule

The rule still decides. Never make a decision in the browser that a rule should make.

​
When roles change

A new role arrives with the next token refresh (minutes) or the next sign-in; end sessions to force it (Roles).

Roles in Auth

Define and assign.

Sensitive actions

Add a second factor.