User management

The user admin page lives at Administration → User admin in the user-menu dropdown. It is where you create staff accounts, set roles, grant access to queues, and control the per-user settings that gate API access and notification style. Admin-only.

The user list

Each row shows a user’s name and email, with a role badge:

1. Sysadmin — can configure system-wide settings and licensing. There is usually one of these.
2. Admin — can configure queues, mailboxes, templates, attachment rules and other admin features.
3. Staff — can sign in to the staff side of Tickiti and respond to tickets in queues they have access to.
4. Unverified — the user has been created but has not yet confirmed their email or set a password. The badge sits alongside whichever role badge is highest.

The roles nest: ticking Sysadmin automatically ticks Admin and Staff; ticking Admin automatically ticks Staff. Tickiti enforces this in the form so a user can never end up admin-without-staff.

The Internal only checkbox below the search box (ticked by default) hides customers from the list so you only see your own staff. Untick it to find a specific customer record (e.g. for ticket assignment as a participant).

Adding a user

1. Click the add-user button (user-with-plus icon) at the top of the user list.
2. Fill in the user’s name and email.
3. Tick the role boxes — Staff at minimum.
4. Click Create.
5. Tickiti emails the user a welcome link they click to verify their email and set their password. The link is signed and expires after seven days; if the user misses it, an admin can delete and re-create the account, which sends a fresh link.

Editing roles

Click into a user to edit. The role checkboxes cover everything Tickiti grants:

1. Staff / Admin / Sysadmin — the nested permission roles described above. The Sysadmin checkbox only appears when the viewer is themself a sysadmin.
2. API user — marks this account as an automation account rather than a person. The user is hidden from participant suggestions on tickets, excluded from agent-activity reports, and removed from staff dropdowns (e.g. intervention assignment). Use this for accounts that exist only to drive Tickiti via the API or to receive automated mail; it stops them cluttering up human-facing lists. It does not grant or restrict access to the API itself — that is governed separately under Authentication and tokens.
3. Tonic notifications — sends notifications using the simplified Tonic template instead of the full email format. Useful for staff who want a leaner inbox; the content of the notification is the same, only the formatting differs.

Queue access

The lower half of the edit pane is the per-queue access table. The columns are:

1. Contribute — sees and can post on tickets in the queue. (See Assignment and queues for what each level grants.)
2. Manage — can take ownership of, reassign and change attributes on tickets in the queue.
3. Delete — can permanently remove tickets in the queue.
4. Administer inbox — for inbox-capable queues, makes this user the fallback for unassigned escalations and other inbox-administrator duties on this queue.
5. Notify inbox errors — for inbox-capable queues, this user receives notifications when the inbox has problems (mailbox failures, parser errors, etc.).

See Queue permissions for how queue access fits with the other access mechanisms.

Removing or disabling a user

To remove a user’s ability to sign in, untick all role boxes and save — their account survives (so audit history continues to work) but they can no longer log in. To delete the account entirely, click Delete user (trash icon at the top of the list).

Deleting a user that owns tickets does not delete the tickets — their email is preserved on the responses they wrote, so the audit trail remains intact. Personal watchlists and perspectives owned by the deleted user are removed.