In one sentence
The Users admin page is where every person in your organization is provisioned, role-assigned, seat-assigned, and password-managed — with two ways to add new people (email invite or temp-password handoff) and a per-user permission grant if you need to give a single individual a capability without changing their role.
- Two add-user paths. Invite by email sends a magic link and the user sets their own password. Create with temp password skips email entirely — the admin gets the temp password back once and shares it out-of-band. Pick the path that matches your security posture.
- Three layers of capability. Base role (Admin / Standard User) is the floor. Additional roles layer on extra permissions. Per-user permission grants are the surgical tool for "give this one person this one thing" without inventing a new role.
- Seats are a billing concept. Each member has a seat type (Full, Approver, R&A). Seats are billed; downgrading is free, upgrading enforces your plan's cap.
The Users page
Admin → Users. Reachable with Edit org settings, or with either of the two Account Recovery permissions — the page renders only the actions the holder actually has.
The page lists every active member with their base role, additional roles, seat type, and inline actions. Search by name or email.
Each row carries quick affordances:
- Access tier dropdown — Admin / Standard User / Read & Acknowledge, changed in place.
- Additional roles chips — add or remove custom roles inline.
- MFA column — what second factors that member has enrolled, or an amber No 2FA chip.
- Reset password — generate a one-time temp password and force a change on next sign-in.
- Reset MFA — clear a locked-out member's second factors. See Account recovery below.
- Deactivate — soft-remove a member and reassign their open work.
- Manage permissions — open the per-user permission grants panel.
Adding a new user
Two paths, both behind the Add user button.
Path 1 — Invite by email
Sends a magic-link email through Supabase's invite flow. The user clicks the link, sets their own password, and lands authenticated.
Use this when:
- The user has a working email address you trust.
- Your auth policy allows password sign-in (or you've already wired up SSO for their domain).
- The user's email domain matches your org's Allowed email domains policy if one is set — otherwise the invite is rejected up-front with a clear error.
The pre-filled fields on the invite form become the user's profile state immediately: full name, base role, seat type, optional additional roles, facility scope. They don't have to set those themselves — they pick a password and they're in.
Path 2 — Create with temp password
Skips email entirely. The admin types the user's details, the system generates a temp password, and the dialog shows that password once. The admin shares it out-of-band (in person, on paper, in a different secure channel).
Use this when:
- Email isn't trusted or isn't available (manufacturing-floor workstations, contractors with no corporate mailbox).
- Your org's policy is to never send credentials over email.
- You need to onboard a batch of users right now and can hand them their first-time password directly.
The user's must_change_password flag is set so their first sign-in forces a password change immediately. The original temp password becomes useless after that one sign-in.
The temp password is shown exactly once. There's no way to retrieve it later. If you close the dialog before sharing the password, run Reset password on the user to generate a new one.
Base role vs additional roles vs per-user permissions
QFormance has three layers for granting capability — pick the layer that matches the scope of the grant.
Base role
Every user has one — Admin or Standard User.
- Admin has every permission and bypasses training gates. Use sparingly.
- Standard User has the minimum —
moc.createandexemption.createonly by default (customizable). Everything else comes from the layers below.
The base role is in the row's dropdown. Changing it is logged to Auth activity as a Role changed event with from/to values.
The system refuses to demote the last remaining Admin in the org. Without this guard, an admin could lock the entire organization out of admin-gated settings. If you genuinely need to swap admins, promote the new admin first, then demote the old one.
Additional roles
Custom roles you've created (Quality Manager, Lead Auditor, Document Reviewer, etc.) layered onto a user on top of their base role. A user can hold any number.
Manage additional roles inline on the row — pick a role from the Add role picker, or click ✕ on a chip to remove. See Roles & permissions for how custom roles are built.
Per-user permission grants
Sometimes you want one person to have one capability without creating a whole role for it. The Manage permissions action opens a panel listing every catalog permission with the user's current effective state.
- Permissions that the user gets from their base or additional roles are shown as granted by role (locked — you can't subtract from a role's permissions on a single user).
- You can directly grant any extra permission, layering it on top of role-derived ones.
- You can revoke a previously-granted direct permission.
Use direct grants sparingly — they're harder to audit than roles. The right answer is usually to create or extend a custom role; the per-user grant exists for the cases where that's overkill.
Seat types
Three seat types, each with different capability and price:
| Seat type | What they can do | Notes |
|---|---|---|
| Full | Everything their role permissions allow — author, approve, investigate | Standard licensable seat |
| Approver | Read documents, approve in their queue, no authoring | Lower-cost seat for executives / reviewers |
| Read & Acknowledge (R&A) | Read distributed documents, acknowledge them, use Ask the Library — nothing else | See Read-and-Acknowledge users |
Seat type lives in its own dropdown on each user row.
Downgrading (Full → Approver, Approver → R&A) is always free and immediate.
Upgrading (R&A → Approver, Approver → Full) enforces your plan's seat cap. A Starter org capped at 10 Full seats can't move an 11th R&A user to Full — the action errors with a clear message about what's available. Either deprovision an existing Full user or upgrade your plan first.
Every seat-type change re-syncs your Stripe subscription so the cost line items match within seconds. See Billing & seat overages for the cost mechanics.
Account recovery
Two of the actions on this page — resetting a password and resetting MFA — are grouped under their own Account Recovery permission group, separate from general user management. Getting a locked-out colleague working again is a help-desk job; changing branding, facilities and roles is an administrative one, and an org shouldn't have to hand over the second in order to delegate the first.
| Permission | What it allows |
|---|---|
Reset member passwords (users.reset_password) | Generate a one-time temporary password for another member, forcing a change at next sign-in. Does not sign out their existing sessions. |
Reset member MFA (users.reset_mfa) | Clear another member's second factors when they're locked out, signing them out everywhere. |
Both default to Admin, and Admins hold every permission, so nothing changes for your existing admins.
Recovery-only delegates
Holding either recovery permission is enough to reach Admin → Users, and the page then renders only what the holder actually has. A delegate with recovery permissions but not Edit org settings sees:
- The member list, with the MFA and password-reset actions on each row.
- A blue banner explaining that their access covers account recovery only, so the missing controls read as a policy rather than a bug.
They cannot invite members, create accounts, change access tiers, grant or remove roles, edit per-user permissions, or deactivate anyone. Those all need the full user-management permission.
A password reset plus an MFA reset is most of an account takeover, and not all of it: the member still has to confirm their email address before they can enroll a new second factor, and nothing in the product lets an administrator change someone's sign-in email. That gap is what stops a recovery delegate from simply becoming another member. Grant the permissions to people you'd trust with a help desk, and review the grant when their job changes.
Resetting a password
Click Reset password on a user row. A confirmation dialog opens. Confirm, and the system generates a new temp password, sets must_change_password = true, and shows you the password once.
Share the new password out-of-band the same way you would for Create with temp password. The user signs in once with it, immediately gets prompted to set a real password.
This is the right flow for:
- A user whose account you suspect is compromised — reset and force a change.
- A user who never signed in after their original invite expired.
- A user who's simply forgotten their password.
A password reset does not touch their second factors and does not end their existing sessions. If they're stuck at the second-factor challenge, a new password won't help — see below.
Reset events land in Auth activity as Password reset with the target name.
Resetting MFA
The shield icon on each row resets that member's multi-factor authentication when they've lost their authenticator app AND their recovery codes. It clears both (and optionally their passkeys and security keys), signs them out of every device including trusted ones, and leaves their password alone.
The dialog requires a reason of at least ten characters — it goes on the permanent audit record, so write how you know the request is genuine, not just that one was made. The member and every admin in the org are then emailed, with a link to cancel.
Two guards you'll notice on the row:
- The action is disabled on your own row. You can't reset your own MFA; ask another admin.
- It's disabled for members with no second factor enrolled — there's nothing to clear, and they'll be prompted to set one up at their next sign-in anyway.
The MFA column on each row shows what that member has enrolled — Passkey, Authenticator, or an amber No 2FA chip for anyone who can't yet complete an MFA sign-in.
Account recovery covers the full escalation ladder, what the member experiences afterwards, and what to do when the org's only admin is the one locked out.
What this page doesn't do
- It doesn't delete people. Members are deactivated, not removed — deactivation is a soft action that reassigns their open work and keeps their name on every record they signed, which is what a regulated audit trail requires. The org's last remaining Admin can't be deactivated, and you can't deactivate yourself.
- It doesn't manage SSO directly. SSO sign-in is configured at Admin → Organization → Auth Policy; this page just creates the user record. An SSO user signs in via their identity provider; this page is irrelevant to their first sign-in if you're SSO-only.
- It doesn't grant cross-org access. Users belong to exactly one organization. There's no concept of an external collaborator with multi-org membership in the customer-facing product today.
Related
- Account recovery — the full lockout escalation ladder
- Roles & permissions — how the role system works
- Read-and-acknowledge users — the R&A seat type in detail
- Auth & sign-in policy — sign-in methods, domain restriction, step-up
- Auth activity — where role changes and password resets are surfaced
- Billing & seat overages — how seat costs are calculated
- Pricing & seat model