Platform members
On this page
Admin Console → Platform members (/platform/settings/users) administers the installation’s sign-in accounts and the platform-admin flag. It is not a personal settings screen - a signed-in person changes their own password from their Account - and it is not where organization membership is administered: that is Members and roles, one tier down.
The distinction is load-bearing, and it was learned the hard way. This list is installation-wide by definition, which is exactly why it belongs at the platform tier: shown on an organization page, it listed people who belonged to a different tenant, and creating an account from there produced someone who was a member of no organization and could sign in to nothing.
Who may use it
Every route is restricted to platform admins, checked as a deployment-level role rather than an RBAC permission. That is deliberate: a grantable permission to mint platform admins would itself be a privilege-escalation surface.
A flag, not a role
Platform-admin standing is one boolean column, users.is_platform_admin, and nothing else. There was a users.role column beside it - holding platform_admin, the earlier spelling superadmin, or user - derived from the flag at write time with no database constraint keeping the two in sync. That column has been dropped. The flag is the sole authority.
It is read from the database on each privileged check, never carried on the session token. That is what makes a promotion or a revocation take effect within the check’s cache window instead of waiting out a session that can be up to 24 hours old.
The API writes isPlatformAdmin: boolean. For one release it also accepts a deprecated role alias in a request body - platform_admin, superadmin, or user - mapped straight onto the boolean and never written back anywhere. Send the boolean.
The rename does survive in the gateway configuration: AUTH_ALB_PLATFORM_ADMIN_GROUP replaces AUTH_ALB_SUPERADMIN_GROUP, which is still read as a fallback and logs a warning at boot. See Environment variables.
Listing
The list shows each account’s email, name, platform-admin flag, and password-rotation status. It is ordered platform-admins first and then by email, rather than by creation date - the flag is the reason to open this list. It is paginated by the engine, 25 accounts to a page - the endpoint takes a limit and an offset and answers { users, total }, so a large installation does not ship its whole account list to a browser.
Creating an account
Click New user. Creating from this page always produces a platform admin - stated, not selected.
That is not a restriction so much as an honest one: creating an account here joins no organization and no workspace, so an ordinary account minted from this page would have nowhere to sign in to. To create an ordinary member, invite them into an organization instead.
Fill in:
- Email - must be a valid email address.
- Name - display name.
- Initial password - optional. Leave blank to auto-generate.
Save. If the password was auto-generated, the panel shows it once on screen. Copy it now - there is no way to see it again. Hand it over out of band.
The new account is marked for a password change on its first sign-in.
Promoting and demoting
The edit dialog sets and clears the flag in both directions. The system prevents removal of the last platform admin: the guard counts the accounts holding the flag and refuses the demotion - a self-demotion included - when that count would reach zero.
A non-boolean isPlatformAdmin is rejected, not coerced. There is no request validation on the route, so a value like "off" would be truthy in the guard and false in Postgres: the guard would see no demotion while the database performed one, leaving the deployment with no platform admin at all.
Resetting a password
Reset password generates a new temporary password, marks the account as needing a change, and shows the new password once. Communicate it out of band.
Resetting drops the user’s existing sessions, so the new temporary password is required on the next sign-in.
This is one of three distinct reset paths, and they are deliberately not merged:
| Path | Authenticates on | Delivers |
|---|---|---|
| this one | a platform admin’s session | a generated password, over HTTP, never by email |
| self-service reset | possession of an emailed token | a link, never a password |
| own-password change | the user’s own session | nothing |
A password is never emailed by this product - generated or temporary. A password in a mailbox is a permanent credential sitting in plaintext in an inbox, on a relay, and in whatever backs both up.
Impersonation
Managed services. Impersonation is available with Polyant managed services.
A row’s action menu can impersonate the account, to see the product as that person sees it.
- Read-only. Only read requests are permitted while impersonating; every mutation is refused, credential actions included.
- A platform admin cannot be impersonated. It gains nothing legitimate and would hand the session every platform-admin route back.
- One at a time, and it expires after 30 minutes - after which it must be started again.
- Start and stop are both audited, keyed to the real administrator, never the impersonated identity.
The action appears as a named menu item rather than an unlabelled icon, and when it cannot be used it says why instead of being silently inert.
Deleting
Delete is permanent, and the account’s sessions are dropped first.
Constraints
- The last platform-admin account cannot be removed or demoted.
- A user cannot delete their own account from this page.
What is audited
Mutations to installation accounts write to the management audit trail: role changes, deletions, password resets, and impersonation start/stop. Creating an account as a platform admin is audited too - the role is applied on creation, so it grants the RBAC bypass in one step with no later change to catch.
A plain rename grants nothing and leaves no row. A password is never recorded, chosen or generated - actor, action and target only.
See also
- Members and roles - the organization tier: memberships and bindings.
- Authentication - what a new account signs in with.
- Audit logs - where the management trail is read.