Skip to content

User Management

The User Management page is where owners and admins invite teammates, change someone’s role, and deactivate accounts. It also exposes per-table read/write/delete permissions for the lower roles.

Click your avatar in the bottom-left of the sidebar, choose Admin to open the System Admin Dashboard, then click the User Management card. The page lives at /:schema/sys/users and is restricted to owner and admin — other roles are redirected to the home screen.

The page has two tabs: Users and Permissions.

The Invite User card at the top takes three fields: email, display name, and role. Click Invite and the system sends a magic-link email to the address. The new user clicks the link and signs in — no separate password setup is required.

Who you can invite depends on your own role:

Your roleYou can invite
Ownerowner, admin, staff, member
Adminstaff, member

Admins can’t invite or promote anyone to admin or owner — only an owner can. See Roles for what each role can do across the platform, and Auth System — invite endpoint for the technical details of how invites are delivered.

Each row in the users table has a role dropdown. The same precedence rule applies: as an admin you can only change someone to a role strictly below admin (staff or member). As an owner you can change anyone to any role. You can’t change your own role.

Click Deactivate to revoke a user’s access and confirm in the dialog that appears. Deactivated users:

  • Can’t sign in or request a magic link.
  • Lose any active session at its next renewal. The renewal interval depends on your org’s session timeout — see Session lifetime for the timing details.
  • Stay in the users list, dimmed, with a Reactivate button to restore access later.

You can’t deactivate yourself, and admins can’t deactivate other admins or owners — only an owner can.

The Permissions tab exposes a per-table grid of read / write / delete checkboxes for the staff, member, and anon roles. Owner and admin always have full access on every table and aren’t shown.

Switch between roles using the buttons above the grid; toggle the checkboxes for any tables whose access you want to change; click Save to apply. Each row-level access change is committed individually, so a failure on one table doesn’t roll back the others — any errors are reported inline.

For the underlying behavior — what defaults each role gets when a table is first created, and how the row-level security policies are kept in sync with the grants — see Database & Schema — managing role access.