Staff roles
The people who run a sol2flow instance have a staff role. Everyone else is "Not staff" and never sees the admin area. There are four roles:
- Owner — everything an Admin can do, and decides who is staff.
- Admin — instance settings, users, workspaces, sign-up approvals and account recovery.
- Support — sees users, approves sign-ups and recovers accounts (with a reason). No settings, no deleting.
- Auditor — read-only: users (with masked email addresses), workspaces and the audit log.
Staff roles are separate from workspace roles (Workspace admin, Member, Guest).
What each role can do
| Permission | Owner | Admin | Support | Auditor |
|---|---|---|---|---|
| Change instance settings (Admin → General, Admin → Authentication: sign-up, sign-in, legal links, retention, API switches) | ✓ | ✓ | – | – |
| Give and remove staff roles | ✓ | – | – | – |
| See users and which workspaces they're in | ✓ | ✓ | ✓ | ✓ |
| See full email addresses | ✓ | ✓ | ✓ | masked |
| Approve or reject sign-ups | ✓ | ✓ | ✓ | – |
| Recover accounts: reset 2FA, remove passkeys, send a password reset, sign out everywhere (always with a reason) | ✓ | ✓ | ✓ | – |
| Create and edit users and their workspace access, revoke API keys, remove profile photos | ✓ | ✓ | – | – |
| Delete and restore users and workspaces | ✓ | ✓ | – | – |
| See all workspaces (names and usage, never content) in Admin → Workspaces | ✓ | ✓ | ✓ (read-only) | ✓ (read-only) |
| Read the audit log (Admin → Audit log) | ✓ | ✓ | – | ✓ |
| Admin of every workspace that isn't private | ✓ | ✓ | – | – |
Admin pages per role
The admin sidebar lists only the pages a role may open. A page the role can't open answers "Page not found", also when the address is typed by hand.
| Page | Owner | Admin | Support | Auditor |
|---|---|---|---|---|
| Users, a user's page | full | full (an Owner's account is read-only) | read, approve sign-ups, account recovery | read-only, emails masked |
| Workspaces | full | full | read-only | read-only |
| General, Authentication | ✓ | ✓ | – | – |
| Audit log | ✓ | ✓ | – | ✓ |
Rules that protect the instance
- Only an Owner changes staff roles, including making someone Admin.
- The last Owner keeps the role and the account: the only active Owner can't be demoted (not even by themselves), disabled or deleted, and can't delete their own account. Make someone else an Owner first. Owners can step down while another Owner remains.
- An Owner's account can be edited, disabled, deleted or have its API keys revoked only by another Owner, so an Admin can't take it over by changing its email or password.
- Account recovery on staff accounts (any role) is for Owners only, so Support can't take over an admin account. Nobody can recover their own account from the admin area; they use Settings → Security instead.
- Every staff role change is recorded in the audit log (from → to).
Assigning a staff role
To give someone a staff role, or change it:
- Open Admin → Users and select the person.
- Under Staff role, pick Owner, Admin, Support, Auditor or Not staff. Below the control you see what the chosen role allows; Compare all roles shows the full table.
- Confirm with Change role. The dialog lists what the person will gain and lose. The change takes effect right away.
You can also set the role when you create an account with Add user.
If you use single sign-on, a provider's Admin group gives its members the Admin role on sign-in, and the optional Support group gives the Support role. Group sync never changes an Owner (or an Auditor set by hand) and only removes a role that its groups gave. See Sign-in.
The first Owner
A new instance needs one Owner to start with. How to create it during installation is described in Installation. After that, the Owner assigns every other staff role in Admin → Users.
Staff in workspaces
Owner and Admin staff are automatically Workspace admin of every workspace that isn't private. Support and Auditor staff get no automatic access to workspaces. Admin → Audit log shows every event, including what happens inside workspaces.
Private workspaces
A workspace admin can make a workspace private. Staff then get no automatic role in it: only people added to it explicitly can open it. In Admin → Workspaces it is still listed (name, members, storage), but without a link, marked No access. On a user's page it appears with a shortened name, such as "No••••••".