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

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.

Workspace Requests: plan changes and deleting the workspace

Settings → Workspace Requests is for Tenant Admins only. Project Admins don’t have it in Settings, and opening its address tells them it is for Tenant Admins. The page has two panels: Plan change and Danger zone.

Plan change

The panel shows the current plan and whether billing is Active or Past due. Request a plan change asks for a plan and a reason — both are required — and sends them to our team, who review the request and apply the change. Business is not offered here: Business plans are set up with our team, so a Business workspace gets Contact support instead.

Under Latest request you see the last request and its status: Waiting for review, Approved, being applied, Applied or Rejected, with the reviewer’s note when it was rejected. One request is open at a time: while it is waiting or being applied, Request a plan change stays on the page but does nothing, and a note says you can send another once this one has been reviewed.

Deleting the workspace

Any Tenant Admin can delete the workspace from Danger zone → Delete workspace. Opening the dialog emails you a one-time deletion code. Enter it, tick the box confirming you understand that all of the workspace’s data will be deleted, and choose Delete workspace.

• The code is six letters and numbers, and capitals don’t matter. It works for 15 minutes. There is no resend link: close the dialog and open it again, and a new code replaces the old one.
• Nothing is deleted straight away. The workspace is scheduled for deletion 48 hours later, and everyone keeps working until then.
• Every Tenant Admin is emailed, and the Tenant Admin who scheduled it is signed out. The sign-in page then says when the workspace will be deleted and how to cancel.
• Everyone sees it. While a deletion is scheduled, a red strip across the top of every page says when, and who scheduled it. It can’t be hidden. Tenant Admins also get a reminder dialog when they sign in.
• Any Tenant Admin can cancel with Cancel scheduled deletion: on the strip, in the sign-in reminder, or in the Danger zone. Every Tenant Admin is emailed when it is cancelled.
• Times are shown in your own timezone. The emails give them in UTC.

After 48 hours it can’t be undone. Everything in the workspace is deleted for everyone, including projects, test cases, runs, results and attachments. Business workspaces are closed with our team: contact support to delete one.

How to change a user's Access Level

1. Go to Settings → Users.
2. Find the user and click the value in their Access level column.
3. Pick the new level. It is applied immediately — there is nothing further to save.
4. 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.