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. That role applies to every project they are a member of, unless a Project Role Override is set for a specific project.

Roles contain only project-level permissions — things like managing test cases or viewing reports. They cannot grant admin panel access 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 Admin → Users → Roles & Permissions. From there you can:

• Create a new role with a custom name, description, and permission set
• Edit an existing role's permissions (changes apply to all users with that role immediately)
• Set a role as the workspace default
• Delete a role — users assigned to it are automatically moved to the default role

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.

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, Delete, Execute, or Add and manage results on Test Runs automatically includes View Test Runs.
• Granting Create, Delete, Edit and close, or Add and manage results on Sessions automatically includes View Sessions.
• 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 Project Cycles automatically includes View Project Cycles.
• Any role with at least one permission automatically includes View Projects, allowing the user to see the projects they belong to.

View permissions cannot be removed while dependent action permissions are active. In the role editor, a View permission checkbox will be locked if any action permission in the same category is still selected. To remove the View permission, first uncheck all action permissions 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 — edit the user in Admin → Users → All Users and change the Role field

"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 where they do not have a Project Role Override set. Projects where an override is active are not affected. See Project Access & Overrides if you need per-project control.