Users
Overview
This is where the platform's accounts are managed — the sign-ins of your own staff. Customer access has its own surface, see Portal access; the two are never mixed.
An account carries the sign-in address, a display name, optionally a profile picture, a role and optionally a link to an employee profile. The email address is the sign-in address and has to be unique.
Core tasks
Create an account. New user asks for email, name and the access route. There are two routes:
| Route | Sequence |
|---|---|
| Invitation by email | The person receives a link and sets their own password. The account stays inactive until then. |
| Set a password now | You assign an initial password (at least 10 characters) and pass it on securely. |
The invitation route is the better one: a password you know and hand over stops being a secret the moment you hand it over.
Assign a role. The role determines the permissions and applies across brands. Without a role, the account has base access only.
Link to an employee profile. The link to personnel master data is a precondition for time tracking, among other things. An employee profile can belong to exactly one account.
Resend an invitation. When editing, a fresh invitation can be triggered. The account is set back to "inactive/invited" until the password is set — which closes the old access immediately.
Deactivate an account. The toggle in the list blocks access without destroying the history. That is the right route when somebody leaves: deleting would destroy the traceability the audit log provides.
Sign in as another user. The button with the sign-in arrow in an account's row opens a confirmation: you give a reason (required) and — if your own account uses two-factor authentication — the current code. After that you see and use the application with exactly that person's permissions, for 60 minutes at most. Above every page the notice "You are viewing the application as …" stays in place together with the End button; it brings you back as yourself to the user management. This is the way to reproduce a reported view without asking for a password.
What applies:
- Start and end are separate entries in the audit log; every change during
the session carries both identities — the person's as actor and yours as "signed in by".
- Not possible: yourself, portal accounts, deactivated accounts, accounts that may sign in as others
themselves, and accounts with permissions you do not hold — signing in would otherwise extend your permissions.
- No further session starts from a running one, and the person's two-factor settings cannot be
changed meanwhile.
Survey what exists. The list shows name, email, linked employee, last sign-in and the active state. "Never" in the sign-in column points to an account that was never taken up.
Fields in detail
The What it does column answers what changes in the system — not what the field is called. The grey name behind the label is the API field: the same thing runs under that name through automation, import and AI tools.
Creating and editing a user account
| Field | Required | Values / format | What it does |
|---|---|---|---|
Email address email | yes | address, max. 255 characters | The sign-in address. It is the account's identity; the invitation goes there. Changing it changes the login — no detail. |
Display name displayName | no | text, max. 255 characters | How the person appears in the system. Kept jointly with the employee record. |
Role roleId | no | an existing role | What the person may do. Without a role they may do nothing — sign in, yes, but open no page. Permissions come exclusively through roles, never directly on the account. |
Employee employeeUlid | no | an existing employee record | Connects account and personnel file. Without this link the person can neither request an absence nor record their own time — they have no "self" in the system. |
Language locale | no | one of the configured languages | Language of the interface and of notifications. |
Active active | no | yes/no | Off blocks sign-in at once without deleting the account. This is the right route when someone leaves: deleting would strip every document and log entry of its author. |
New password newPassword | no | text as specified | Sets the password from outside. The route for a locked-out colleague — they should change it themselves afterwards. |
Resend invitation resendInvitation | no | yes/no | Sends the invitation mail again. Its link is time-limited; expired it is worthless, and that is exactly what this switch is for. |
Signing in as another user
| Field | Required | Values / format | What it does |
|---|---|---|---|
Account userUlid | yes | an active staff account | The person whose view you take over. Their permissions apply for the whole session — yours rest meanwhile. |
Reason reason | yes | text, max. 500 characters | Stored with the session in the audit log. It later answers why somebody acted as this person. |
Code mfaCode | only with your own two-factor authentication | 6-digit code or recovery code | Your own two-factor duty applies here too; without a valid code no session starts. |
Settings & permissions
- Permission
platform.user.manage. Without it the page is unreachable. - Permission
platform.user.impersonate. Allows signing in as another user; out of the box only
the GF/Admin role holds it.
- Minimum password length: 10 characters.
- Profile pictures are limited to image files (PNG, JPG, WebP, GIF).
- What the account may do lives in the role — not here. Permissions are defined under
FAQ & troubleshooting
The invitation does not arrive. Check the person's spam folder first, then the system's mail dispatch. As long as the invitation is not taken up, the account stays inactive — the person cannot sign in.
An employee cannot be selected. Then they are already linked to another account; the list says so. A double link is impossible.
The user signs in but sees almost nothing. Then the role is missing, or it carries too few permissions.
I want to delete an account. Deactivate it instead. A deleted account would take its trail in the logs with it.
The "Sign in as …" button is missing. It only appears with the permission platform.user.impersonate, not in your own row, not for deactivated accounts and not while you are already signed in as someone else.
The session ends by itself. After 60 minutes it is over; the next action brings you back as yourself.