The Super admins section is where you manage who can use the Platform Console and with which console role. It is also how a deployment is handed over: the client's own people take the Owner role, and the Jadiroon team steps out.
Where to find it
Super admins in the console sidebar (/admin/admins), for roles holding Super admins & roles view; inviting and changing super admins needs Act. Its Roles tab manages the console roles themselves (see Console roles). The list shows each super admin's name and email, role, status (Active, Pending activation, Stepped out), two-factor status (Authenticator app, Not enrolled) and last sign-in.
Inviting a super admin
Invite super admin asks for an email, a full name and a console role, for example:
- Owner — full console access, including entering workspaces as their Workspace Admin.
- Viewer — read-only Overview and Workspaces.
- Any role your deployment created, such as a Taxonomy editor or an HQ Recruiter.
Roles beyond your own access are disabled in the picker. Only an Owner can invite an Owner, or a role that manages super admins.
The invitee receives an activation email. The link is valid for 7 days. Opening it, they set a password of at least 12 characters, then link an authenticator app (see below) and land in the console. Until then they show as Pending; Resend activation link sends a new link and the old one stops working. If the email can't be sent, the console says so and shows you the activation link instead, so you can pass it on yourself; both the invite and the resend are recorded in the Activity log.
Signing in with two-factor
Two-factor authentication is always on for super admins. Signing in at /admin/login takes two steps:
- Email and password.
- The 6-digit code from your authenticator app (Google Authenticator, Microsoft Authenticator or similar).
The first time (at activation, or at your first sign-in if you skipped it), the console shows a QR code and the key as text. Scan it with your app and enter the code it shows. Super admins must use an app: email codes cannot be chosen as the main method. Once the app is linked, Email me a code instead is there as a fallback if your phone is not at hand.
- The console never remembers a device. Every sign-in asks for a code.
- Five wrong codes end the attempt ("Too many wrong codes. Start again."); start again from the password.
- An attempt lasts 10 minutes from the password step. If it runs out, for example while you set up the authenticator app, you go back to the password ("This sign-in attempt expired, start again.").
- After twenty wrong codes within an hour, sign-in is blocked for an hour ("Too many wrong codes. Try again in an hour.").
- Every wrong code by a super admin, and every enrolment or reset, is in the Activity log.
- If you are blocked while linking your app for the first time, wait the hour, or ask whoever runs the server for the break-glass reset (below).
Changing your authenticator app
Security in the console sidebar (/admin/security, every super admin) shows your status, for example "Authenticator app — on since 21 Oct 2026". To move to a new phone:
- Change authenticator app, then enter a code from your current app. If your phone is not at hand, use Email me a code instead.
- Scan the new QR code (or type the key) and enter the code the new app shows.
The new app replaces the old one at once. You stay signed in on this browser, while your other console sessions and any workspace you entered end. You get an email, and the change is in the Activity log. Email is never a saved method (a code by email works for one sign-in only), and the console keeps no list of trusted devices. If you no longer have your old app and cannot receive email, ask another Owner to reset your two-factor.
Resetting a super admin's two-factor
If a super admin loses their phone, another super admin with Super admins & roles Act opens the actions menu on their row and picks Reset two-factor, then confirms. This:
- removes their authenticator app,
- ends their console session, and any workspace visit they have open, on their next request,
- emails them, and records
mfa.resetin the Activity log.
Their password does not change. At their next sign-in they link an app again. Nobody can reset their own two-factor, a role without Act cannot reset anyone, and only an Owner can reset an Owner.
If the only Owner is locked out, whoever runs the server can reset them with the break-glass command (npm run mfa:reset -- <email> --platform --break-glass). It emails that super admin and every other active Owner, and the Activity log marks it as break-glass.
The Users page has the same Two-factor column and Reset two-factor action for workspace users, for example a Workspace Admin who has no other Workspace Admin to reset them.
Changing a role
Change role gives a super admin another console role. They lose the sections the new role doesn't hold at once, and any workspace visit they have open ends on their next request; their next entry uses the new role's entry role. You can only give roles within your own access, and only an Owner can move someone to or from Owner. Each change is in the Activity log.
Stepping out and back in
- Step out disables a super admin. Their console session stops working on their next request, and so does any workspace visit they have open. Nothing they did is removed; the Activity log keeps it.
- Step back in re-enables them with their existing password.
The platform always keeps at least one active Owner. You cannot step out or demote the last active Owner.
Handing a deployment over
A dedicated client deployment is typically handed over like this:
- A Jadiroon Owner invites the client's administrators as Owners.
- They activate their accounts and confirm they can sign in.
- The client's Owners step out the Jadiroon team's super admins.
From then on, only the client's Owners can bring a Jadiroon super admin back, by stepping them back in from the console. Every step is in the Activity log.
Server-side recovery
Whoever runs the server can create a super admin, or recover access if no Owner can sign in, with a command run on the server. This is the way the first Owner of a new deployment is created.
If that command is used to re-enable a super admin who was stepped out, it clears their password — they must activate again through a new link — and it emails every active Owner that the account was re-enabled from the server. It is also recorded in the Activity log. A client therefore always learns when access was restored outside the console.
Running the command again for a super admin who is already active changes nothing about their sign-in: it never sends a new link on its own. If an active super admin has lost their password, the command must be run with an explicit reset option. That clears their password, signs them out everywhere, sends them a new activation link, records the reset in the Activity log and emails every active Owner, the same way as a re-enable.