User, role, and group management lives under Admin → Users & Roles, a separate area from the Settings page — reachable to admins, and to managers for a reduced subset. It has four sub-tabs: Users, Roles, Groups, and Permissions.
Adding a user
From the Users tab, click Create New User and fill in display name, email, password, an initial role, and a reporting manager — the manager field is required, not optional, since several approval and configuration-change flows route through it. Search the user list with the search box, and adjust how many rows show per page.
Managing an individual user
Each row in the Users tab has its own set of actions: add or remove roles inline, change or clear their reporting manager, assign them to a Customer record (see Customers & Vendors) and see that customer's tier, deactivate or reactivate the account, mark or unmark them as VIP (which affects how their tickets are triaged elsewhere), unlock an account that's been locked out after failed logins, force an admin password reset (generates a one-time reset link you copy and share), reset their two-factor enrollment, or delete the account outright.
Adding users in bulk
Click Bulk Upload, download the provided spreadsheet template, fill in a row per user, and upload it — the same fields as the individual create form, applied to everyone in the file at once.
Roles and permissions
The Roles tab lists every role, tagging the built-in ones (admin, manager, agent, employee, readonly) as System — those can't be deleted, though custom roles you create can be. Create Role just needs a name and description; permissions are assigned afterward through the role's permission editor, which groups every available permission by module (incidents, changes, CMDB, and so on) with a running count of how many are granted, so you can see at a glance how broad a role is.
The Permissions tab is where those underlying permissions themselves are managed — a searchable list of every permission in the system, with the option to define a custom one for a resource that doesn't have a built-in permission set yet.
Groups
Creating a group (name, description, an optional inbox email) is only the first step. A group can also have one or more roles linked directly to it — anyone added as a member automatically inherits whatever roles are linked to their group, on top of anything assigned to them individually, which is the fastest way to grant a whole team the same access without editing each person. Members themselves are added from a separate search-and-add control on the group.
Setting a group's persona tier
A group's tier — the thing that actually determines its members' workspace, default landing page, and visibility (see Personas & Access Tiers) — is set separately, under Settings → People & Access → Group Tier: pick the group, pick a tier (L1.5 through L5), and optionally link a role from the same screen.
Access Control — deciding exactly what a role can see
Beyond broad module permissions, Admin → Access Control offers two finer-grained controls:
- Row Visibility — per role and per record type (incidents, problems, changes, catalog), choose how much of the list that role sees: everything, their group plus their own, their group only, or only what they personally own. Anything left unconfigured defaults to the most restrictive option.
- Field Access — per record type, pick a specific field and set it to read or write, gated behind a permission you choose. Useful for something like hiding a sensitive custom field from most roles while still letting a specific permission unlock it.
Example
A new L2 analyst joins the team. Rather than assigning permissions one by one, the admin adds them to the existing "L2 Technical Analysts" group, which already has the right role linked to it and its tier set to L2 — the new hire gets the correct workspace and visibility the moment they're added, no individual configuration needed.