Roles

A Role is a named set of permissions that defines what a user can do inside projects — for example, creating test cases, executing test runs, or viewing reports. It applies across all projects by default.

How Roles work

Each user has one Role assigned to them. It applies in every project whose access default is their own workspace role and where no exception says otherwise. A project can also hand a single role to everybody, in which case that role is used instead.

Roles contain only project-level permissions — things like managing test cases or viewing reports. They cannot grant workspace administration or tenant-wide capabilities. Those are controlled by Access Level.

The default role

Your workspace has one role marked as the default. Any new user who is invited without an explicit role selection will automatically receive the default role. Only one role can be the default at a time, and it cannot be deleted while it is set as default.

Managing roles

Roles are managed under Settings → Roles & permissions. From there you can:

• Create a new role with a custom name, description, and permission set
• Edit an existing role's permissions on its own page (see below)
• Set a role as the workspace default
• Delete a role — users assigned to it are automatically moved to the default role

Creating and editing roles needs Starter. On Free, every role in the workspace stays visible and assignable, and any of them can still be made the default. New role carries a lock and a Starter chip: a billing admin’s click opens the plan, anyone else’s sends an upgrade request. Delete leaves the row menu and the role editor opens read-only. See Plans and Billing.

The role editor is a page of its own

Opening a role — from its name, or Edit permissions in the row’s actions menu — takes you to that role’s own page, with a crumb back to the Roles tab. Name, description and the whole permission matrix are edited there.

Changes are not written as you tick them. A bar appears at the foot of the page as soon as anything differs, naming how many changes are pending, and offering Discard and Save role. Once saved, the new permission set applies to everyone holding that role. Leaving the page with changes pending prompts you first.

Available permissions by category

When building a role, you select from project-level permissions organised by module. Each permission grants a specific capability within the project:

Admin permissions are not listed here. Permissions like Invite Users, Manage Roles, or Create Projects do not appear in the role editor — they are granted by Access Level, not by Roles. If you cannot find a permission in the role editor, it is likely a tenant-level permission.

Who can assign testers in a run

Two Test Runs permissions decide who can put a tester’s name against a case in a run:

• Create and start — assign anyone: any case in an open run, to any tester, or back to nobody.
• Execute — pick up any open case for yourself, including one another tester already holds, and hand back only your own.

Only people who can execute tests in the project can be assigned: someone whose role there lacks Execute is not offered as a tester. The ready-made roles include both permissions, so this matters only for roles you build. See Assigning Testers.

View permissions and how they are implied

When you grant any action permission — Create, Edit, Delete, or Manage — the corresponding View permission for that category is automatically included. This ensures users always have the read access required for the actions they are allowed to perform.

• Granting Create, Edit, or Delete on Test Cases automatically includes View Test Cases.
• Granting Create and start, Delete, or Execute on Test Runs automatically includes View Test Runs.
• Granting Create, Delete, Edit and close, or Add and manage results on Explorations automatically includes View Explorations.
• Granting Create/edit/delete on Folders automatically includes View Folders.
• Granting Create and manage on External References automatically includes View External References.
• Granting Create/edit/delete on Cycles automatically includes View cycles.
• Any role with at least one permission automatically includes View Projects. That is what lets the user see projects in the workspace navigation — it does not open Settings → Projects, which follows the Access Level.

Bulk-editing test cases is not offered here. Bulk edit test cases is a real project permission, but it is deliberately kept out of the role editor — it reaches users only through the built-in Access Levels. If you went looking for it in this list, that is why it is not there.

What a role without View external references does not see. The ready-made roles a workspace starts with all include it, so this only matters for a role you build without it. Someone with such a role still sees the project’s test cases and runs, but not the issues linked to them: issue keys, titles and counts are left out of the test case list (grouped by Linked issue, it shows one Linked issues hidden group), a run’s cases and results, its sign-off snapshot, and the run list. Filtering on linked issues is refused. The MCP tool get_cases_for_issue looks only in projects where the key owner has the permission, and is refused when they have it in none.

View permissions cannot be removed while dependent action permissions are active. In the role editor, clearing a View permission has no effect while any action permission in the same category is still selected. To remove the View permission, first clear every action permission in that category.

Assigning a role to a user

A user's Role is set in two places:

• At invitation time — the invitation form includes a role selection field
• After joining — change the Role directly in the row, or in the edit dialog, on Settings → Users

"If I change someone's Role, does it affect all their projects?" Yes — the Role is a workspace-wide default. Changing it updates what that person can do in every project that resolves to their own role for them. It does not affect a project where they carry an exception set to a specific role, or one that hands a single role to everybody. See Project Access & Overrides if you need per-project control.