Skip to main content

Roles & Permissions

Roles define what each user can do in your Qase workspace, which entities they can access and which actions they can perform.

Updated today

⚠️Custom Roles are available in Business and Enterprise subscriptions

Roles define what each user can do in your Qase workspace, which entities they can access and what actions they can perform on them.

Overview

Every workspace includes three built-in roles. Qualifying paid plans can also create custom roles with granular permission control. A user's license type (regular, read-only, billing) always takes precedence over their role, a read-only user with an Administrator role is still read-only. See Users for details on license types.

Built-in roles

Role

Description

Owner

The person who created the workspace. Full control over all features, including other users' private projects. There has to be one owner per workspace; ownership can be transferred to another regular user.

Administrator

Same permissions as the owner, except they cannot transfer ownership or access the owner's private projects (unless explicitly shared).

Member

Access to all core Qase features, creating and running tests, managing defects, using dashboards. This is the default role assigned to new invitees unless you change it.

Creating a custom role

Navigate to Workspace → Roles and select Create a new role. You'll configure three things:

  1. Role title and description - choose something your team will recognize (e.g., "QA Lead", "External Auditor").

  2. Set as default - optionally make this role the default for all new members joining the workspace.

  3. Permission matrix - for each entity type (projects, suites, cases, runs, plans, defects, etc.), toggle whether users with this role can create, read, update, or delete.

The permission matrix is entity based. For each entity, you control:

  • Create - can they create new instances?

  • Read - can they view existing instances?

  • Update - can they modify existing instances?

  • Delete - can they remove instances?

Some permissions are contextual. For example, disabling "Create" on test runs prevents a user from starting runs, but they can still execute tests within a run someone else created (if they have "Update" permission).

Changing the default role

The default role is assigned to every new member who joins via invitation or SSO. To change it, go to Workspace → Roles, find the role you want as default, and select Set as default. You can set any role except Owner as the default.

How roles interact with project access

Roles control what actions a user can perform. Project membership controls which projects they can see. A user needs both the right role permissions and project access to act on an entity.

FAQ

Can I edit the built-in roles?
No. Owner, Administrator, and Member are fixed. Create a custom role if you need different permissions.

What happens if I delete a custom role that's assigned to users?
Users from the deleted custom role will be assigned the default role.

Does the role apply to API access too?
Yes. API tokens inherit the permissions of the user who created them.

Did this answer your question?