Skip to main content

Users and sign-up

Admin → Users lists everyone with an account on the instance, across all workspaces. Every staff role can open it; what you can change depends on your role (see Staff roles).

Finding people​

The list shows each person's name, username, status, sign-in method, staff role and workspaces. A Verified or Unverified badge next to the name shows whether their email address is confirmed (see Email verification); sign-ups that haven't opened their confirmation link yet have the status Awaiting verification. To narrow it down:

  • Use the status chips: All, Active, Pending approval, Staff, Invited, Disabled.
  • Filter by Staff role, by sign-in method (Password, Any OIDC provider or a specific provider), by workspace, and by Email (Any email, Verified or Unverified).
  • Search by name, username or email (Auditors can't search by email: they see addresses masked, such as j•••@client.io).
  • Sort by name, username, creation date or status.

The Users item in the sidebar shows a yellow badge with the number of sign-ups waiting for approval.

A user's page​

Select a person to open their page. It shows:

  • the account (name, username, email, sign-in method, status) with Edit account;
  • Email address: whether the address is verified, and since when (see Checking an address);
  • their Staff role (only Owners can change it);
  • Workspace access: every workspace they belong to, with their role, join date and the workspace's member count;
  • whether two-factor authentication is on, how many recovery codes are left, their passkeys, sessions and API keys (never secrets);
  • Account recovery, for staff who may recover accounts;
  • the Disable account switch and Delete user.

Workspaces you can't open​

A person's page lists all their workspaces, even ones you can't open yourself (a private workspace you aren't a member of). Those appear with a shortened name ("Hi••••••"), read-only, and link to their row in Admin → Workspaces, which shows every workspace's full name.

Changing workspace access​

Owner and Admin staff can change a person's workspace memberships from their page:

  1. Open Admin → Users and select the person.
  2. To add them somewhere, choose Add to workspaces, pick the workspaces and a role, and confirm.
  3. To change or remove existing memberships, select rows in the workspaces table and use Set role… or Remove from workspaces.

You can only add people to, or change, workspaces you're allowed to manage.

Workspace creation per person​

The instance-wide rule for who may create workspaces is in Admin → General (see Instance settings). To override it for one person, set Can create workspaces on their page to Instance default, Allowed or Not allowed, and optionally a limit. Owners and Admins can always create workspaces.

Adding and editing accounts​

To create an account:

  1. Open Admin → Users and choose Add user.
  2. Enter the name, username, email and a password (or Generate one), and optionally the workspaces to add them to.
  3. Owners can also give a Staff role here.
  4. Leave Mark email as verified ticked (the default) if you know the address belongs to this person. Untick it to send a verification link to the address instead. The account can sign in either way, but until the address is confirmed it doesn't match invitations or workspace join domains.
  5. Save.

To change an account, open it and choose Edit account. Leave the password field empty to keep the current password. Accounts that sign in through an identity provider have their password managed there. An email address you change here applies right away and counts as verified; the change is recorded in the audit log.

Disabling an account​

Disable account blocks sign-in without deleting any data. The person's sessions stop working and their API keys are refused. Turn the switch off again to reactivate the account. Only Owners can disable an Owner's account, and the last Owner can't be disabled.

Deleting an account​

  1. Open the person's page and choose Delete user.
  2. The dialog shows what will happen, then asks you to confirm.

The same rules apply as when people delete their own account:

  • Blocked while the person is the only admin of a workspace that other people still use, or the last Owner of the instance. Make someone else an admin or Owner first.
  • Workspaces where they are the only member are deleted with the account and can be restored during the grace period (Admin → Workspaces → Deleted workspaces).
  • Their tasks, comments and time entries stay, shown as "Deleted user".

You can't delete your own account here. See Data export and deletion for details.

Account recovery​

When someone is locked out — a lost phone, a lost passkey, a forgotten password — staff with the right role can help from the person's page. Owner, Admin and Support staff can recover accounts; staff accounts can only be recovered by an Owner, and nobody can recover their own account here.

To recover an account:

  1. Open Admin → Users and select the person.
  2. Under Account recovery, enter a Reason of at least 10 characters — for example the ticket number and what the person asked for.
  3. Choose the action and confirm it:
    • Reset two-factor authentication — deletes their authenticator setup and recovery codes. They sign in with their password only until they set it up again. Passkeys are not touched.
    • Remove passkey or Remove all passkeys — for a lost or shared device. They keep their password (or single sign-on) and can add new passkeys.
    • Send password reset email — sends the same single-use link as "Forgot password", valid for 60 minutes. Their current password keeps working until they choose a new one. Only for accounts with a password and an email address.
    • Sign out everywhere (in the sessions list) — ends every session of the account. Their API keys keep working; revoke them separately if needed.

Every action is recorded in the audit log with your reason, and the person is emailed about it. The email doesn't include your name or the reason.

warning

Verify who you're talking to before you reset two-factor authentication or send a reset link. Account recovery bypasses the protections the person set up, so treat each request like a password reset over the phone.

Owner and Admin staff can also revoke a person's API keys from their page (the person is emailed) and remove their profile photo.

Self sign-up​

By default, accounts are created by staff or by accepting an invitation. You can also let people create a password account themselves from the sign-in page.

To set up self sign-up:

  1. Open Admin → Authentication.
  2. Turn on Self sign-up.
  3. Optionally restrict it with Allowed email domains (comma-separated; leave empty to allow any domain).
  4. Choose which workspace New accounts join and with which role — or No workspace.
  5. Turn on Require admin approval if new accounts should wait until staff approve them.
  6. Leave Require email verification on (the default) so new accounts confirm their address before they can sign in — see Email verification.
note

These settings, including approval, apply to password sign-up only. Accounts created on first sign-in through single sign-on follow the provider's own settings (create users on first sign-in, default workspace and role, group mappings) and are active right away — except that Require email verification also applies to them when the provider doesn't confirm the address (see Single sign-on accounts). See Sign-in.

If Terms of service URL or Privacy policy URL is set in Admin → General → Data & legal, the sign-up form shows a checkbox that must be ticked.

Email verification​

Require email verification (in Admin → Authentication, under Sign-in methods, right below Self sign-up) is on by default. With it on:

  • new accounts confirm their address with an emailed link before they can sign in;
  • a changed email address only applies once the new address is confirmed (see Account and security);
  • single sign-on accounts whose provider doesn't confirm the address get the same confirmation email.

Only Owner and Admin staff can change the setting, and every change is recorded in the audit log. Sign-up with verification needs working email: if your instance can't send email, turn the setting off (Email).

With the setting off, sign-up works without a link: new accounts are signed in right away (or wait for approval), and a changed address applies immediately, unverified.

What happens at sign-up​

  1. After Create account, the person sees Check your email with the address they typed. They can Resend email, choose Opened the link on another device? Continue, or choose Wrong address? Sign up again, which deletes the unconfirmed account so the username is free again.
  2. The email, "Confirm your email address for …" (your instance's name), contains a link that works once, for 24 hours. Sending a new link makes older ones stop working.
  3. Opening the link in the same browser signs them in and continues to the usual start page — this is also when they join the workspace set in New accounts join. Opened in another browser or on another device, the link confirms the address and asks them to sign in ("Your email address is confirmed. Sign in to continue.").

Until the link is opened, nothing else happens: no sign-in, no workspace membership, no welcome email. If someone signs in before confirming, the right password shows Verify your email first with Resend email, and no session is created; a wrong password shows the usual "Wrong username or password.", so nothing reveals that the account exists. Resending is rate-limited per address and per IP address.

With Require admin approval also on, the account waits for approval only after the address is confirmed: the link page then shows Waiting for approval, and staff are notified only at that point (see Approving sign-ups).

Accounts that count as verified​

These addresses are treated as confirmed without a link:

  • accounts created by accepting or finishing an invitation — the invite link proves the address. This includes an unconfirmed sign-up that opens an invitation sent to its address and signs in from there;
  • single sign-on accounts whose provider confirms the address (see below);
  • accounts created in Add user with Mark email as verified ticked;
  • the first administrator from BOOTSTRAP_ADMIN_* and accounts created with the create-admin script (Installation).

Single sign-on accounts​

When an identity provider sends email_verified: true for the address, the account counts as verified. When it doesn't — Microsoft Entra ID, for example, sends no such claim — and verification is required, a new single sign-on account gets the confirmation email and a Check your email page first. After confirming, the person signs in with the provider again; that's when groups, the default workspace and the other provider settings are applied.

With Require email verification off, addresses from single sign-on count as verified, as before.

For a provider you trust to manage its addresses (such as Microsoft Entra ID), turn on Trust this provider's email addresses in its settings (off by default): its addresses then count as verified even without email_verified. Changes are recorded in the audit log. See Sign-in.

What a verified address is used for​

Only a verified address matches invitations sent to it and the email domains of a workspace's join requests (Join requests). Someone whose address isn't confirmed sees no workspaces they could ask to join until it is.

Checking an address​

A person's page in Admin → Users has an Email address card: Verified on … with the date, or Unverified. Staff who can recover accounts (Owner, Admin and Support; a staff account only by an Owner; never your own) also get:

  • Resend verification email — sends a new link to the address.
  • Mark as verified — after a confirmation. Only do this if you know the address belongs to the person. An account waiting for verification is then activated (or waits for approval, if that's required).

Both actions are recorded in the audit log.

An address someone else signed up with​

If someone signs up with an address that isn't theirs and never confirms it, the address's owner can still take it over. When they sign up with it, sign-up says That email is already in use. and offers Send a confirmation email to this address. sol2flow sends a link only when the address belongs to an account that was never confirmed; for any other address nothing is sent, and the answer on screen is the same, so it reveals nothing new. The link works once, for 24 hours, and is rate-limited like Resend email.

Opening the link shows which unconfirmed account would be removed ("This will remove the unconfirmed account … that used this address"). After Remove it and continue, that account is deleted and sign-up continues with the address filled in and already confirmed: the person chooses a username and password and is signed in (or waits for approval). Verified accounts are never affected. The audit log records the deletion with the email domain only.

Unconfirmed sign-ups are deleted​

A daily job deletes self sign-ups that stayed unconfirmed for 7 days. Accounts created by invitation or by staff are never deleted this way. The audit log records each deletion ("Unverified account deleted") with the email domain only, never the address.

Instances that existed before​

When an instance is updated to a version with email verification, every existing account that has an email address is marked as verified (since the date the account was created), so nobody is locked out, and Require email verification is turned on.

Approving sign-ups​

With Require admin approval on, new accounts are Pending approval: they can't sign in until someone approves them. With Require email verification also on, an account only reaches this point once its address is confirmed.

Every Owner, Admin and Support staff member is told when a sign-up is ready for approval — in the notification bell and by email — and the Users badge counts it.

To approve or reject a sign-up:

  1. Open the notification, or go to Admin → Users and select the Pending approval chip.
  2. Open the person's page. A banner shows when they signed up.
  3. Choose Approve or Reject, and confirm.

Approving activates the account. Rejecting deletes it; the person can sign up again if self sign-up stays open. Whoever decides first, every other staff member's notification shows the outcome ("Approved by …").