Team Members
What this screen is for
A person has one account across ANKASecure — one email, one name and the authenticators they sign in with — and belongs to your tenant through a membership. The same person can belong to other organizations too, with other roles there. This screen, opened by the Users entry of the sidebar, lists the memberships of your tenant. From here you add a person, follow their invitation until they accept, decide which roles they hold in your tenant, suspend them and remove them.
You manage the membership, never the account: nobody on this screen sets, sees or resets a person's password, passkeys, name or email.
The three tiles count the people listed, the active memberships, and those still pending.
What must exist first
Both SIMPLE and STANDARD tenants use this screen. Before you work here:
- The permission to list users or to create them, which is what shows the sidebar entry. Reading a person's roles and changing them are two further permissions: without the first, a person's detail has no Roles tab.
- The permission to create, update or delete users, each held separately. The federated-link actions, without the permission they need, are shown disabled and say which one is missing.
- A working email channel: the person receives their link by mail, and the console never shows it. The wizard warns you when your tenant's delivery is not ready.
On a SaaS deployment, a platform operator working inside your tenant under a support-access session cannot add a person or change anyone's roles: both requests are refused.
Decisions you make here
Reading the list
Each row shows the person's display name, email, roles in your tenant, membership status and how they sign in to your tenant. Sign-in says whether the membership is local or linked to your identity provider.
Last sign-in is when the person last signed in to your tenant, or switched into it from another organization. It reads Never for a membership never signed into. Renewing a session does not move it, and signing in elsewhere never does.
The status is ACTIVE, PENDING (added, not yet accepted — the person cannot sign in to your tenant) or SUSPENDED. A PENDING row shows the address only: nothing of the person's account appears until they accept, whether they are new to ANKASecure or already belong to another organization. Search matches names and emails; the filter narrows by status.
A row can carry a recovery badge. Must enrol a new authenticator means the person can sign in again only after setting up a new authenticator. Recovery requested means your tenant asked for the person's account to be recovered, and Recovered, awaiting enrolment that the platform did so and the person has not set up their new authenticator yet.
Adding a person
Create User opens a two-step wizard. The first step asks for the Email only. The second offers the built-in tenant roles that can be assigned in your tenant, or No role (assign later).
When you confirm, the person is added as a PENDING membership and receives a link by email:
- someone new to ANKASecure gets an activation link, where they set up how they will sign in: a passkey, or, where your tenant's sign-in requirements admit it, a password and an authenticator app. A password alone never activates the account, and nobody else chooses the person's credential;
- someone who already has an account gets an invitation link and accepts by signing in with the passkey or password they already use. When what they hold does not meet your tenant's sign-in requirements, they are asked to add an authenticator that does, and the membership becomes active once they have. When your tenant admits them through its identity provider, they are sent there once they have signed in.
The wizard ends on Invitation sent, the same for both cases: you are never shown the link, and you cannot tell whether the person already had an account. An address that is already a member of your tenant is refused, and so is the address of a platform administrator, who never becomes a member of a tenant.
Following up a pending invitation
The Pending invitations tab lists every PENDING membership, with when it was added and when its link expires. Re-send link emails a new link and stops the previous one from working; you are never shown it. A person who accepts leaves this tab.
Assigning roles
The eye icon opens the person's detail; with the permission to read roles, its Roles tab lists the built-in tenant roles as checkboxes and shows which the person holds in your tenant. With the permission to change roles, Save replaces that set with exactly what is ticked. The request is refused when a ticked role would confer a permission you do not hold yourself, and you cannot change your own roles.
Custom roles composed on the roles screen are not offered here. One assigned through the API appears in this tab as a legacy granular assignment, which Save preserves and Replace legacy with composite removes.
When a change takes effect depends on its direction:
- A role added reaches a person who is signed in when their session token is next renewed, or at their next sign-in. Nobody is signed out.
- A role removed, or any change that takes a permission away, ends the person's sessions in your tenant immediately. Their sessions in other organizations are not touched.
Suspending and reactivating
Suspend membership stops the person from signing in to your tenant and ends their sessions here; their roles are kept, and their access to other organizations is untouched. Reactivate membership lets them back in.
Linking a federated identity
The Overview tab shows how the membership signs in. With the permission to update users, and the permission to read identity providers, Authorize a link lets a subject of one of your tenant's identity providers be bound to this membership: you name the provider, and a window of 72 hours by default, 168 at most. The binding happens at the first matching sign-in through that provider.
If your tenant signs members in through the identity provider only, a linked membership can only be reached through that provider, even by a person who has a password for other organizations.
Restricting one member to the identity provider
Signs in shows whether the member signs in As the tenant admits or Through the identity provider only. With the permission to manage your tenant's authentication policy, Restrict to the identity provider stops the member's password and passkeys from entering your tenant; a sign-in proven locally is offered the provider instead. Sign in as the tenant admits gives the member back the ways your tenant admits. Other members are not affected.
The restriction needs a link to an active OIDC or SAML provider of your tenant and is refused while your tenant signs members in Here only. You cannot change it for someone holding permissions you lack. Every change is written to your audit log.
Withdraw authorization cancels a window still open. Unlink returns the membership to local sign-in and ends the person's sessions in your tenant only. No earlier password is restored; a person who has none sets one with Forgot password on the sign-in page.
Designating a break-glass member
Under Break-glass identity in a member's sheet, with the permission to manage break-glass access, Designate as break-glass makes the member one of your tenant's emergency accounts, and Clear the designation undoes it. A designated member signs in only through Emergency access on the sign-in page, with a security key or a device-bound passkey, and each such sign-in raises a security alert.
Use a dedicated account: one linked to an identity provider, restricted to it, or belonging to another organisation is refused. You must have confirmed your identity recently, and the last ready designation of a tenant that signs in through the identity provider only cannot be cleared, nor that member removed. A designation cannot be changed from an emergency-access session.
Requesting account recovery
A person who has lost every passkey and authenticator app, and their recovery codes, cannot sign in. You cannot reset their authenticators yourself: they belong to the person's account, which serves every organization the person belongs to. Request account recovery, the lifebuoy icon of the row, asks the platform's recovery authority to do it. It is not offered for yourself, for an invitation not yet accepted, or while your tenant's request is still pending.
Filing the request changes nothing by itself. When the platform performs it, every passkey, authenticator app, recovery code and password of the person stops working, every session they have ends, and the platform hands them a one-time enrolment code to set up a new authenticator. No administrator learns or chooses the new credential. A person who signs in through your tenant's identity provider is recovered there, not here.
On an ANKA-hosted deployment your request is what allows the platform to recover the person: without it, the platform does not reset the credentials of your users. Only your own administrators can file it; a platform operator acting on behalf of your tenant cannot.
Removing a person
The trash icon, shown for everyone except yourself and the protected system administrator, asks you to type the person's email. The membership is removed immediately, with its roles and links in your tenant, and the person's sessions here end. Their account and their other memberships remain; removing a PENDING membership withdraws the invitation.
How it relates to other screens
What a role lets a person do is decided on the roles screen; this screen only says who holds which:
A person's Activity tab shows the administrative audit events attributed to them. The same trail, for the whole tenant, is the audit log:
A person's open sessions in your tenant are listed and ended on the token management screen:
People are not cryptographic actors: an actor is the identity of an application, authenticates with a credential and never signs in here.