Access Levels
Access Level controls two things: which parts of workspace administration a user can see in Settings, and which tenant-wide actions (like inviting users) they can perform. It does not control what a user can do inside a project — that is the Role.
The three levels
| Level | Workspace administration | Can invite users? | Can manage roles? | Can create projects? |
|---|---|---|---|---|
| Regular User | None — Settings shows personal sections only | No | No | No |
| Project Admin | Part of Settings | No | No | Yes |
| Tenant Admin | All of Settings | Yes | Yes | Yes |
Regular User
The default level for most team members. Regular Users administer nothing — their Settings carries their personal sections and no workspace groups. They can open every project whose access rules allow it, which by default is all of them; what they can do inside is determined by their Role. See Project Access.
Project Admin
Grants a scoped set of the workspace groups in Settings. Project Admins get the whole of Settings → Projects — creating, editing, completing, setting a project’s access default and exceptions, and deleting. Creating and editing do not require going through Settings at all: the project editor is reached from the Projects page and from the sidebar row menu, because it answers to this Access Level rather than to admin membership. Beyond projects they also get a broad set of workspace-level settings.
Specifically, a Project Admin can manage templates, fields, statuses, workflows, cycle types, tags, environments, and external integrations — all of which are configured once for the whole workspace, not per project.
Project Admins cannot:
- Invite users. Inviting is reserved to Tenant Admins — a Project Admin can see the workspace’s users but not add one. Attempting it is refused by the server.
- Manage roles or change anyone’s Access Level.
- Change authentication settings — see Authentication.
“Limited” means limited to people, not to settings. The line between Project Admin and Tenant Admin is drawn around users, roles, and authentication — not around workspace configuration. If you need someone to set up templates and fields but not to hand out access, Project Admin is the level you want.
Tenant Admin
Full administrative access. Tenant Admins can manage all users, create and modify Roles, configure workspace settings, and perform all Project Admin actions. Assign this level carefully — it grants full control over the workspace.
How to change a user's Access Level
- Go to Settings → Users.
- Find the user and click the value in their Access level column.
- Pick the new level. It is applied immediately — there is nothing further to save.
- What the user sees in Settings updates on their next page load.
You cannot change your own Access Level. The control on your own row is inert and says so. This is intentional — it prevents accidental self-demotion and privilege escalation. Another Tenant Admin must make the change.
Access Level and invitations
When inviting a new user, you set their Access Level as part of the invitation form. It applies from the moment they accept. Nothing is preselected — pick one of the three levels yourself.
Sending invitations requires the Tenant Admin level. Project Admins do not have it, so the invitation actions are not available to them.
"Why can't I put admin permissions like Manage Users into a custom role?" Permissions like Manage Users and Manage Roles are tenant-level permissions — they are granted exclusively by Access Level, not by Roles. Roles can only contain project-level permissions (test cases, runs, etc.). This separation is intentional: it prevents anyone with role-editing access from accidentally granting themselves or others admin capabilities.