Platform Users
What this screen is for
This screen, opened by the Users entry of the platform sidebar under the title User Management, administers the people of the platform plane, and reaches into the tenants for the few repairs a tenant cannot make for itself. A person has one account across the installation — one email, one name and the authenticators they sign in with — and belongs to each tenant through a membership; the account itself is managed only here. The screen has up to four tabs:
- System Users: the operators of your installation — the people who sign in to this console in the platform context. It is the same screen as a tenant's Team Members, mounted on the platform tenant, so what that page says about adding a person, assigning roles, linking a federated identity and removing a membership holds here. This page covers only what differs.
- Pending Activations: every membership, in every tenant, still waiting for its person — an invitation of someone new, or of someone who already has an account and accepts by signing in.
- Tenant Users: the members of one customer tenant, where you appoint an additional tenant administrator or correct a login email.
- Account recovery: the requests tenant administrators filed to recover a person who lost every authenticator, oldest first.
Pending Activations and Tenant Users are not offered on an ANKA-hosted deployment. Account recovery is offered on every deployment type: recovering a person reads no tenant data, and the person asked for it.
What must exist first
This is a platform screen: opening it while you are working inside a tenant sends you to that tenant's users screen. Before you work here:
- The permission to list users, or the permission to read pending activations; either shows the sidebar entry. The built-in platform administrator, operator, auditor and viewer roles hold both. Each tab follows its own read: without the pending-activations permission the second tab is absent.
- To see a person's account in their detail — their email, name, activation and every tenant they belong to — the permission to read identities, held by all four built-in platform roles. Renaming and deleting a person, and forcing a password reset, are further permissions held by the built-in platform administrator only; each control is shown only with its permission.
- To cancel an invitation on Pending Activations, the permission to cancel pending activations, held only by the built-in platform administrator.
- For the Account recovery tab, the permission to read recovery requests, held by the built-in platform administrator, operator and auditor, not the viewer: a request names a person who lost every authenticator. Performing a recovery is a further permission, held only by the built-in platform administrator.
- For the Tenant Users tab, the permission to appoint tenant administrators, which also covers correcting an email, together with the permission to list users. Only the built-in platform administrator holds the first.
Decisions you make here
Inviting a platform operator
Create User on System Users is the tenant wizard with two differences: it may give a new account its starting display name, and the roles it offers are the built-in platform roles — PLATFORM_SUPER_ADMIN, PLATFORM_OPERATOR, PLATFORM_AUDITOR, PLATFORM_VIEWER — or No role (assign later). A platform administrator is never a member of a customer tenant, and a member of a customer tenant can never be added here: use a different address for each role a person plays. Platform administrators reach a tenant only through consented support access.
A new platform operator activates the account with a passkey, or with a password and an authenticator app: the platform plane admits both, and offers the passkey first.
Assigning platform roles
The Roles tab of a system user's detail offers the platform composite roles, and Save replaces the person's set with what is ticked. Ticking a role that would confer a permission you do not hold yourself is refused. Adding a role reaches a signed-in person when their session token is next renewed; removing one ends their sessions immediately.
Your own account is read-only here and says so: nobody changes their own roles.
The platform always keeps a PLATFORM_SUPER_ADMIN who can sign in with a passkey, a password and an authenticator app, or an approved identity provider. Unticking that role from the last such person, suspending or removing them, deleting their account, unlinking their identity provider, or designating them for emergency access is refused, whoever asks, and nothing changes: give another platform administrator the role and a way to sign in first. Emergency access does not count as a way in.
The person behind a membership
The Person section of a user's detail shows the account itself: its email, whether it was ever activated, whether a password reset is pending, its Display name — which you can change, and every tenant then shows — and Member of, every tenant it belongs to. Removing a person from a tenant never deletes them: a person with no tenant left can sign in to nothing, and Delete identity retires them. It is offered only once no membership remains.
When the person must set up a new authenticator, or a recovery was requested or performed, the section shows a Recovery row with the same badges as the user lists, and who requested the recovery. With the permission to perform recoveries, Recover recovers the person from here, answering the tenant's pending request when there is one.
A person's open sessions, in every tenant, are listed and ended on the platform token management screen, by the User ID shown in the person's detail.
Under Break-glass identity, the platform super administrator designates a platform administrator for emergency access, or clears it. A designated administrator signs in only through Emergency access, with a security key or a device-bound passkey, and each such sign-in raises a platform security alert. The account must be dedicated to the platform and hold no identity provider link.
Forcing a password reset
Force Password Reset acts on the person's one password, used in every tenant they belong to. It stops that password from working, ends every session the person has in every tenant, and emails one reset link, which you are also shown so you can hand it over when the mail does not arrive. The dialog warns you first when your deployment's email delivery is not ready. A person who has never set a password is refused: re-send their invitation instead.
Following up invitations across tenants
Pending Activations lists every pending membership on the installation, with its tenant, when it was added, when its link expires and whether it is PENDING or EXPIRED, sorted by date, name or email. Regenerate Activation Token, with its own permission, voids the previous link and emails a new one. To repair a mistyped address, use the third tab instead.
The Type column tells two kinds of row apart, as the platform decides them. An Invitation is a person who has never had an account; their link lets them set up how they will sign in — a passkey, or a password and an authenticator app where the tenant admits it. An Acceptance is a person who already has an account — they belong to another tenant — and accepts by signing in with the passkey or password they already use, adding an authenticator first when the tenant requires one they do not hold.
Cancelling an invitation nobody will accept
Cancel activation, on an Invitation row only, removes that membership from its tenant and stops its link from working. The dialog names the address and the tenant. An Acceptance is never cancelled here: the tenant withdraws it by removing the membership.
To clear several at once, tick the invitations — the header box ticks every invitation on the current page — and choose Cancel selected (n). One confirmation lists them all; each is then cancelled on its own, and a summary names every row as cancelled or refused, with the reason. Each cancel is recorded in the audit trail of the tenant concerned, under your name.
Recovering an account
Account recovery lists the requests, with the person, the tenant that asked, who requested it, when, and whether it is Pending or Performed, filtered by status. A request is filed by a tenant administrator, who cannot reset a person's authenticators: they belong to the person's account, which serves every tenant.
Recover asks you to confirm, then invalidates every passkey, authenticator app, recovery code and password of the person and ends every session they have, in every tenant. It cannot be undone.
You are shown a One-time enrolment code, valid for one hour, once: this console does not keep it. Hand it, or the enrolment link that carries it, to the person through a channel you trust; with it they set up a new authenticator, which you never learn. You cannot recover your own account, and a person whose memberships all sign in through an identity provider is recovered by that provider.
On an ANKA-hosted deployment, a person of a customer tenant is recovered only to answer a Pending request one of their tenants filed, and only while that tenant still has the person as a member: the provider never resets a customer's user on its own initiative. Without such a request the recovery is refused, nothing changes, and the refused attempt is recorded in the audit trail. Platform administrators, and every person on a deployment your organization operates, can be recovered without a request.
Appointing an additional tenant administrator
On Tenant Users, choose a tenant — your own platform tenant is not offered — and its members are listed with their status. Appoint as tenant administrator adds the built-in TENANT_ADMINISTRATOR role to that membership and keeps whatever roles it already holds. The grant is permanent: it does not expire, and only the tenant can withdraw it. A Pending member can be appointed once their invitation is accepted.
The appointment is refused when the membership or the tenant is not ACTIVE, and answers a conflict when the person already holds the role. It is recorded in that tenant's own audit trail, under your name.
Correcting a login email
Correct login email changes the address the person signs in with — in that tenant and in every other tenant they belong to. The platform stores it in lower case, the previous address stops working at once, and every session the person had, in every tenant, is ended.
This is the repair for a tenant created with a mistyped administrator address. Any link already sent stops working; the link the person still needs is issued to the new address, and the result tells you whether one was. If an outstanding link cannot be voided, nothing is changed and the correction is refused.
How it relates to other screens
The tenants whose members the second and third tabs reach are created and governed on the tenants screen:
What a platform role lets its holders do is decided on the platform roles screen; this screen only says who holds which:
A person's sessions are listed and ended on the platform token management screen:
Inside a tenant, its own administrator adds people, assigns the tenant roles and withdraws an appointment made here: