Users & roles

#Users & roles

The Auth area (sidebar → Auth) is where you manage who can sign in and what they're allowed to do. It has four tabs: Users, Roles, API Keys, and Crews.

#Managing users

The Users tab lists every account. From here you can:

• Create a user — + Add → + User, top right; set email, name, password, and role
• Import users — + Add → Import Users: bulk-import from another system, including legacy password hashes (phpBB, WordPress, bcrypt, argon2) that verify on first login and upgrade automatically
• Edit or ban — click any row to edit it, or use the row's own buttons to change a role or block sign-in without deleting the account
• Search — by name, email, or username, across every account rather than the current page
• Filter — by role, and by status (Active, Deactivated, or All)
• Sort — click any of the Name, Email, Role or Created headers; click again to reverse
• Paginate — 25 per page, with the total shown above the table

Search, filters, sort and page all live in the address bar, so a filtered view can be bookmarked or shared and survives a reload. The ✕ in the search box resets the search and both filters together.

Deactivated accounts are hidden by default — set the status filter to Deactivated or All to see them. This is also how you reach a deleted user: deleting is a deactivation, so the account is still there and can be restored with the reactivate button.

How new accounts appear depends on the signup mode chosen at setup (changeable in Settings → Sign-in):

Mode	Who can create accounts
disabled	Only you, from this page (recommended)
invite	People you invite
open	Anyone with the URL

#The built-in roles

Every instance seeds five roles. The first four are assignable; public is what an unauthenticated request gets.

Role	Intended for
super_admin	Instance owners. Passes every permission check — cannot be locked out
admin	Day-to-day administrators. Manages users (below admin), roles, settings, schema, and system tools
editor	People who create and edit records
viewer	Read-only access
public	Unauthenticated visitors — only sees what you explicitly grant

Admins can't touch super_admin accounts, and can't grant the super_admin or admin roles when creating users. That containment is enforced by the permission system itself, not by UI convention.

#How permissions work

A role is just a bundle of permission rows. Each row grants one action on one resource:

resource:  collections/posts     (or schema/*, system/users, lens/templates, …)
action:    read | create | update | delete | manage | …

Two optional fields make grants precise:

• item filter — a row-level filter compiled into every query. {"author_id": "$CURRENT_USER"} means "only rows you own". Filters can reference $CURRENT_USER, $CURRENT_ROLE, $PROJECT_ID and $NOW.
• validation — constraints on written values. {"role": {"_nin": ["super_admin", "admin"]}} is how the admin role is prevented from creating admins.

Create custom roles on the Roles tab when the built-ins don't fit — for example a support role with system/users:read and nothing else. Collection pages also offer access presets that write these permission rows for you.

Click anywhere on a role's bar to open it. Each bar shows how many users hold the role and how many permission rows it carries. Delete sits inside the opened panel rather than on the collapsed bar, so you see what a role grants before you can remove it; the confirmation names the role and says how many people it affects. The four built-ins (super_admin, admin, editor, viewer) cannot be deleted.

#API keys

API keys are first-class callers: each key resolves a real role (never super_admin) and can be narrowed further with per-key scopes. They're managed on the API Keys tab — see API keys for creation, scoping, and rotation.

#Flocks

Flocks are groups of people — a flock is a crew in the API. They are an audience for sharing: hand a record to a flock and every member reaches it, capped by their tier in that flock. Item filters can no longer name a flock; that mechanism was removed. See Flocks.

#Verifying access — the inspector

Guessing what a role can see is error-prone, so don't: System → Access runs the real permission checks for any role against every collection and reports the effective result — including the row filter that would apply. Use it after changing permissions to confirm the outcome matches your intent.

#What you learned

• Users, roles, API keys, and crews are managed in the Auth area
• A role is a set of resource/action grants, sharpened by row-level item filters and write validations
• Admins are contained by design: they can't reach or mint super_admins
• The access inspector shows a role's effective access, so you never have to guess