Permissions Matrix
The complete permissions reference for all roles and how to configure them.
Permissions Matrix
The permissions matrix provides a complete, action-level view of what each role can do. This is the authoritative reference for understanding default permissions. Permissions marked with -- are off by default but can be toggled on for the User role via the Configure Permissions settings below.
Test Cases
| Action | Owner / Org Admin | Project Admin | User | Guest |
|---|---|---|---|---|
| View test cases | Yes | Yes | Yes | Yes |
| Create test cases | Yes | Yes | Yes | -- |
| Edit test cases | Yes | Yes | Yes | -- |
| Delete test cases | Yes | Yes | -- | -- |
| Clone test cases | Yes | Yes | Yes | -- |
| Import test cases (CSV) | Yes | Yes | Yes | -- |
| Export test cases (CSV) | Yes | Yes | Yes | Yes |
| Create / rename folders | Yes | Yes | Yes | -- |
| Delete folders | Yes | Yes | -- | -- |
| Add/remove attachments | Yes | Yes | Yes | -- |
Test Cycles
| Action | Owner / Org Admin | Project Admin | User | Guest |
|---|---|---|---|---|
| View test cycles | Yes | Yes | Yes | Yes |
| Create test cycles | Yes | Yes | Yes | -- |
| Edit test cycles | Yes | Yes | Yes | -- |
| Delete test cycles | Yes | Yes | -- | -- |
| Execute test cycles | Yes | Yes | Yes | -- |
| Assign test cases to cycles | Yes | Yes | Yes | -- |
| Remove test cases from cycles | Yes | Yes | -- | -- |
Test Plans
| Action | Owner / Org Admin | Project Admin | User | Guest |
|---|---|---|---|---|
| View test plans | Yes | Yes | Yes | Yes |
| Create test plans | Yes | Yes | Yes | -- |
| Edit test plans | Yes | Yes | Yes | -- |
| Delete test plans | Yes | Yes | -- | -- |
| Link/unlink cycles to plans | Yes | Yes | Yes | -- |
Requirements
| Action | Owner / Org Admin | Project Admin | User | Guest |
|---|---|---|---|---|
| View requirements | Yes | Yes | Yes | Yes |
| Create requirements (built-in) | Yes | Yes | Yes | -- |
| Edit requirements (built-in) | Yes | Yes | Yes | -- |
| Delete requirements (built-in) | Yes | Yes | -- | -- |
| Link requirements to test cases | Yes | Yes | Yes | -- |
Defects
| Action | Owner / Org Admin | Project Admin | User | Guest |
|---|---|---|---|---|
| View defects | Yes | Yes | Yes | Yes |
| Create defects (built-in) | Yes | Yes | Yes | -- |
| Edit defects (built-in) | Yes | Yes | Yes | -- |
| Delete defects (built-in) | Yes | Yes | -- | -- |
| Change defect status (built-in) | Yes | Yes | Yes | -- |
| Link defects to test cases | Yes | Yes | Yes | -- |
Reports
| Action | Owner / Org Admin | Project Admin | User | Guest |
|---|---|---|---|---|
| View reports & dashboards | Yes | Yes | Yes | Yes |
| Export / download reports | Yes | Yes | Configurable | Yes |
| Generate insight reports | Yes | Yes | Yes | Yes |
| Use AI test case generation | Yes | Yes | Yes | Yes |
All AI insight reports are read-only and available to every role — this is not a
configurable permission. Only exporting a report is configurable, via Export Reports.
AI test case generation is likewise not role-gated. It is controlled by the organization-wide Enable AI Features toggle and your AI credit balance, not by anyone's role.
Settings & Administration
| Action | Owner / Org Admin | Project Admin | User | Guest |
|---|---|---|---|---|
| Manage project settings | Yes | Yes | -- | -- |
| Manage custom fields | Yes | Yes | -- | -- |
| Manage integrations (Jira, CI/CD, webhooks) | Yes | Yes | -- | -- |
| Manage notification preferences | Yes | Yes | -- | -- |
| Add / remove members of a project | Yes | Yes | -- | -- |
| Invite users to the organization | Yes | -- | -- | -- |
| Remove a user from the organization | Owner only | -- | -- | -- |
| Configure role permissions | Yes | Yes | -- | -- |
| Organization settings & billing | Owner only | -- | -- | -- |
| Create / delete projects | Yes | -- | -- | -- |
| Transfer ownership | Owner only | -- | -- | -- |
Owner only marks the four things an organization Admin cannot do, despite sharing this column everywhere else: manage billing, open the organization Settings page, remove a member, and transfer ownership. Note also that inviting someone to the organization is an organization-level right — a Project Admin who is only an organization Member cannot do it.
API keys are not on this matrix, because they are not role-gated. Personal Access Tokens are per user, not per role: anyone in the organization — including a Guest — can create up to 10 tokens for themselves from Profile → API Keys. A token never grants more than the person who made it. See API Keys.
The tables above show default permissions. Permissions for the User role can be customized per project. Owner, Project Admin, and Guest permissions are fixed and cannot be modified.
Configure Permissions
TestKase allows Owners and Project Admins to customize the permissions for the User role on a per-project basis. This means you can have a stricter permission set in a production testing project while being more permissive in a sandbox or training project.
Owner and Project Admin roles always have full access. Guest role is always read-only. Neither can be modified through the permissions UI.
How to Configure Permissions
- Open the project you want to configure, then go to Settings → User Permissions. (User Permissions is a project setting — it is not in the main left sidebar.)
- You can switch project without leaving the page using the project dropdown at the top.
- You will see all configurable permissions grouped into categories. Each permission has a toggle switch that controls whether Users can perform that action.
- Toggle individual permissions on (blue) or off (grey) as needed.
- Changes are saved automatically. Each toggle takes effect immediately.
Permission Categories
Permissions are organized into the following categories:
Folders
Controls folder management within test cases and test cycles.
| Permission | Default |
|---|---|
| Create Folders | On |
| Rename Folders | On |
| Delete Folders | Off |
Automation
Controls automation mapping features for linking automated tests.
| Permission | Default |
|---|---|
| Create Automation Mappings | On |
| Link Automation to Test Cases | On |
| Delete Automation Mappings | On |
Delete Operations
Controls destructive actions across different artifact types.
| Permission | Default |
|---|---|
| Delete Test Cases | On |
| Delete Test Cycles | On |
| Delete Test Plans | On |
Import / Export
Controls bulk data import and export, including report downloads.
| Permission | Default |
|---|---|
| Import Test Cases | On |
| Export Test Cases | On |
| Export Reports | On |
Attachments
Controls file attachment management on test cases.
| Permission | Default |
|---|---|
| Upload Attachments | On |
| Delete Attachments | On |
Requirements
Controls requirement management. Permissions marked as built-in only apply when the project uses the built-in requirements tracker instead of an external integration like Jira.
| Permission | Built-in only | Default |
|---|---|---|
| Link / Unlink Requirements & Test Cases | No | On |
| Create Requirements | Yes | On |
| Edit Requirements | Yes | On |
| Delete Requirements | Yes | Off |
Defects
Controls defect management. Permissions marked as built-in only apply when the project uses the built-in defect tracker instead of an external integration.
| Permission | Built-in only | Default |
|---|---|---|
| Link / Unlink Defects & Test Cases | No | On |
| Create Defects | Yes | On |
| Edit Defects | Yes | On |
| Delete Defects | Yes | Off |
| Change Defect Status | Yes | On |
Test Cases, Test Cycles and Test Plans
Fourteen further toggles exist beyond the seven categories above, covering the day-to-day work itself. They are configurable for the User role in exactly the same way:
| Category heading in the UI | Toggles |
|---|---|
test_cases | Create Test Cases · Edit Test Cases |
test_cycles | Create Test Cycles · Add Test Cases to Cycle · Remove Test Cases from Cycle · Assign Testers · Execute Tests · Update Test Case Version · Update All Test Case Versions · Reset Cycle Executions |
test_plans | Create Test Plans · Clone Test Plans · Link Cycles to Plan · Unlink Cycles from Plan |
These three sections are labelled with their raw internal names. The page has friendly headings for
the seven categories above but not for these, so they render literally as test_cases, test_cycles
and test_plans — and they sort after every named category, at the very bottom of the page. Scroll
down; they are easy to miss. The permission names inside them read normally.
Whatever a toggle shows on the page is the authoritative answer for what the User role can do in that project right now.
UI Features
Toggle All
Each category header includes a Toggle All switch that lets you enable or disable all permissions in that category at once. The switch shows three states:
- Blue -- All permissions in the category are enabled.
- Grey -- All permissions in the category are disabled.
- Light blue (indeterminate) -- Some permissions in the category are enabled and some are disabled.
Search
Use the search bar at the top of the permissions page to quickly find a specific permission by name. The list filters in real time as you type.
Built-in Only Permissions
Some permissions in the Requirements and Defects categories are marked as built-in only. These permissions only apply when your project uses TestKase's built-in requirement or defect tracker. If you have connected an external tool (e.g., Jira), these permissions do not affect the external integration. Built-in-only permissions are displayed below a grey divider within their category.
What Is Configurable vs. Fixed
Not all permissions can be toggled. The following rules apply:
- Owner and Project Admin permissions are fixed -- These roles always have full access to everything. You cannot restrict any of their permissions.
- Guest permissions are fixed -- The Guest role is always read-only. You cannot grant Guests additional capabilities.
- User permissions are configurable -- All permissions listed in the categories above can be toggled on or off for the User role per project.
- View permissions are fixed -- All roles (including Guest) can always view artifacts they have been granted access to. You cannot revoke view access for a role that has project access.
When you change permissions for the User role, the change applies to all users with that role in that project. There is no per-user permission override -- permissions are always role-based.