User Management
The User Management section lets you create access for persons and manage which person is linked to a user in each tenant.
Setting up access (Activate)
Section titled “Setting up access (Activate)”- Select the desired tenant in the tenant picker.
- Click “Activate” on a person without access.
- Confirm the sign-in address. It is pre-filled with the email address from the person record; if there is none, enter it here.
- Click “Set up access”.
No username and no password are created. The person receives a message “You now have access to …” with a link to the sign-in page, and the message contains no secret. There they enter their address, receive a code by email and are signed in. Afterwards they can set up a passkey (see Passkeys).
Without a sign-in address there is no way in. A person without an address therefore cannot be activated until you enter one.
For multiple persons at once: Check the boxes and click “Activate N selected”. The address from each person record is used. Persons without an address are listed in the result with the reason; activate them one by one.
One account, several tenants
Section titled “One account, several tenants”A person has one account, identified by their sign-in address. If you activate a person whose address already belongs to a roleALPHA account, for example because she also works as a consultant for another customer, that account gets an additional membership in your tenant. No second account is created.
- You do not see whether or where the account exists elsewhere. That is only the person’s own business.
- The person has one passkey and one set of recovery codes for all their tenants. After signing in they choose the tenant, and they can switch without signing in again.
- Roles apply per tenant. Being an administrator at another customer does not make someone an administrator in yours. You assign roles through your tenant’s role management.
- Casing of the address does not matter.
Older accounts: Before this change, a separate account was created for each tenant. If an address still belongs to several such accounts, activation does not guess; it shows a message instead. Platform operations merges these accounts.
Managing sign-in: address and emergency exit
Section titled “Managing sign-in: address and emergency exit”Next to every activated user there is a key icon. Behind it are the two things passwordless sign-in needs.
Sign-in address
Section titled “Sign-in address”Sign-in codes and sign-in links go to this address. It belongs to the account and applies in every tenant the account is a member of. It is not the same as the email address in the person record, even though the two usually match:
- The address in the person record is master data and may be changed by anyone allowed to maintain people.
- The sign-in address is the account’s anchor. Changing it changes who can sign in as this person.
That is why the sign-in address is taken from the person record only once — as long as none is set yet. After that it changes only here, explicitly. If the two differ, the dialog says so.
There is one exception, and it reverses this rule. If the person record is mastered by a data source (Entra ID, SAP, Dynamics), or the tenant has an active SSO provider, the address belongs to that external system. The field is then locked and names the source. With a data source nothing is lost: the sign-in address follows the person record there automatically once the next sync has run. The lock exists because otherwise there would be two truths — one in the external system and one here — and nobody could say which one counts.
The same holds for SSO, by a different route: sign-in recognises the account by a stable identifier from the provider rather than by the address. If the provider changes it, the person still lands in their own account and the sign-in address follows on the next sign-in.
If a locked address must be changed anyway — for instance because the new address already belongs to another account in the tenant and was therefore not taken over — platform operations can do it. Contact support for that.
If the account also belongs to other tenants, you cannot change its sign-in address. It applies there as well, and whoever changes it decides who can sign in as this person, at the other customers too. Only the person themselves or platform operations can change it then. The same rule applies to your tenant’s data sources and SSO providers: they do not update the address of such an account.
An address can belong to one account only. If it is already taken, saving is rejected.
On saving, the previous address is notified about the change. That is not a courtesy: its holder is the only person who can notice a misuse.
If nothing is set here, the person cannot sign in by email — they would receive neither a code nor a link, and without single sign-on or a passkey set up earlier they cannot get in at all. For users without an address in the person record this field is therefore the only way to invite them at all.
Resetting sign-in methods
Section titled “Resetting sign-in methods”The emergency exit for a lost device. It removes all passkeys and all authenticator apps for this person — nothing more:
- No password is set in the process. You do not gain access to the account; you only make it reachable again.
- The person then signs in by email code and sets up a new passkey — exactly as they did the first time.
- The person is notified, even when they asked for it themselves. Without that message, helping out would be indistinguishable from a takeover.
The action cannot be undone and therefore asks for confirmation.
You can trigger it only for accounts that exist exclusively in your tenant. Passkeys and authenticator apps belong to the account and apply in all of its tenants. If a person also has access elsewhere, contact platform operations. An account in another tenant is out of your reach anyway.
Deactivating users
Section titled “Deactivating users”Click “Deactivate” on an active user. Access to your tenant is blocked immediately. A session that is already running can no longer be extended either. If the person has access to other tenants, that access is not affected. You can reactivate at any time; the roles stay as they were.
Only platform operations can lock an account across all tenants.
Person assignments per tenant
Section titled “Person assignments per tenant”A user can exist in multiple tenants — each tenant can have a separate person entity for that user. Via Person Assignments (the
- See which person is linked to a user in each tenant
- Select a different person for a tenant
- Remove an assignment
How to do it
Section titled “How to do it”- Click the
UsersRound icon in a user’s row. - The “Person Assignments” dialog shows all tenants for this user.
- Click “Change Person” to open a person search for that tenant.
- Select the desired person — it is saved immediately.
Note: A person can only be assigned to one user per tenant. If the desired person is already assigned to another user, an error message appears.
Activity: last login
Section titled “Activity: last login”Every activated user shows their last login (e.g. “today”, “5 days ago”, or a date). This lets you see at a glance whether an account is actually used. “Never logged in” and anything older than 30 days is subtly highlighted — handy for spotting stale accounts and deactivating them if needed.
Only a real login counts (email code, sign-in link, passkey or single sign-on) — a background token refresh does not change the timestamp.
Visibility and JWT
Section titled “Visibility and JWT”The assigned person determines the visibility context at login: via the person, group memberships, direct grants, and joker grants are resolved — determining which entities the user can see.