Managing users and roles
The five roles
| Role | Belongs to | Who can create one | Who can manage them |
|---|---|---|---|
| Superadmin | No tenant | Not created through the Users page - a fixed platform account | - |
| Support | No tenant | Superadmin only, via a dedicated "Create support user" action | Superadmin only |
| Admin | One tenant | That tenant's own admin, or a superadmin/support acting on that tenant | Superadmin, support, or that tenant's own admin |
| Instructor | One tenant | Same as admin | Same as admin |
| Member | One tenant | Same as admin | Same as admin |
A tenant admin can only create/manage users within their own tenant - the tenant is picked automatically from their session, not a field they fill in. A superadmin or support agent creating a user must specify which tenant it belongs to, since they aren't scoped to one.
Neither superadmin nor support roles can be assigned through
the regular "create user" or "change role" actions - those are
reserved for the dedicated support-provisioning flow (superadmin-only)
and the platform's own fixed superadmin account, to keep those two
sensitive, tenant-less roles from being handed out casually.
Instructor, unlike those two, is an ordinary tenant-scoped role -
self-service-assignable the same way admin/member are, no special
provisioning flow.
Creating a user
From the Users page, Create user takes a username, email, and
role (admin, instructor, or member - support only appears as
an option for a platform actor, via the separate support-provisioning
action). A temporary password is shown once at creation time, and the
new user is also emailed it directly (unlike tenant creation's own
founding admin, who has no real email on file yet - see Signing
in).
If you're signed in as a tenant admin, the new user is automatically scoped to your tenant. If you're a superadmin or support agent, you choose which tenant the user belongs to.
Changing a role
admin ↔ instructor ↔ member changes are all available from the
role dropdown next to a user in the table. A tenant admin can change
roles within their own tenant; superadmin/support can act on any
tenant.
Support agents must supply a ticket reference for every role change, deactivation, or reactivation they perform - this is enforced by the API, not just a UI convention, and every such action is recorded (see Audit log).
Deactivating and reactivating
Deactivating a user blocks their sign-in without deleting their account or data - useful for offboarding without losing history. Reactivating restores access. Both are available from the same role dropdown area in the Users table, subject to the same tenant-scoping rules as role changes above.
Cross-tenant visibility
Superadmins and support see users across every tenant in one table (with a tenant-name column) rather than needing to select a tenant first. Tenant admins only ever see their own tenant's users - there's no way to switch views, because the underlying data is isolated at the database level, not filtered in the UI.