Users are created inside the product itself. There are no email invitations: an administrator creates the account and hands the login and the temporary password to the person directly.
Every person has a role — it defines what they are allowed to do. The role is read on every action, so a demotion takes effect immediately, not after the next sign-in.
Roles
| Role | What it allows |
| Viewer | View builds, diffs and baselines. Decides nothing. |
| Reviewer | Review verdicts, comments, todos — the role the review board opens for. |
| Member | Queue runs, start campaigns, edit tests. |
| Admin | Project settings, the baselines lifecycle, users. |
| Owner | API tokens, key rotation, owner handover. |
An unknown or missing role is read as viewer. That is deliberate: if something went wrong with permissions, the person gets less access, not more.
The design-approver flag
Separately from the role there is the design-approver flag — it belongs to the person answerable for how shared components look. Without it, a change to the color, font, spacing or layout of a shared component cannot be approved. If such an approval still went through (from an admin, for example), the audit log carries a “without design approval” mark on it.
Why this separation exists: changing how a shared button looks is a decision about the whole product, not about one page — so a separate person delivers it.
Creating and disabling
An administrator adds a user: a login name, a display name, and an initial password of at least four characters. The account is created with the member role — raised later in the same place. The password can be reset at any moment.
A disabled account cannot sign in, but its trace in the audit log stays: you can see that this particular person made that decision — the history of their actions remains in place after disabling too. Managing users requires the admin role; lowering your own role or disabling your own account is not allowed — so you do not lose access by accident.
Access is revoked instantly: permissions are checked on every request, so even an unexpired session of a disabled or deleted person is refused the very next time. There is no need to wait for the session to end, and no need to rotate the shared keys because an employee left.
First sign-in
While there is not a single user in the database, the sign-up form is open by itself. The first person to register becomes the owner — with every right at once. After that registration closes, and only an administrator creates users.
Next: how to hand a long-lived key to the build pipeline and external tools — in API Keys.