Roles & Permissions

Understand TestKase's two-tier role model — organization roles and project roles.

TestKase uses a two-tier role model to control access across the platform.

Organization Roles

Organization roles determine what a user can do at the platform level.

Role	How Assigned	Access
Owner	Created the organization	Full access to everything
Admin	Assigned by Owner/Admin when inviting	Full access to all projects, team management
Member	Default for invited users	Access only to assigned projects

Owner vs Admin

Operation	Owner	Admin	Member
Delete organization	✅	❌	❌
Rename organization	✅	✅	❌
Manage billing	✅	❌	❌
Create/delete projects	✅	✅	❌
List all projects	✅	✅	❌
Invite team members	✅	✅	❌
Remove team members	✅	❌	❌
Resend an invitation	✅	✅	❌
Cancel a pending invitation	✅	❌	❌
Manage org roles	✅	✅	❌
Manage product access	✅	✅	❌
Access all TMT projects	✅ (implicit)	✅ (implicit)	Only assigned projects
Accessibility scans	✅ (own scans)	✅ (own scans)	✅ (own scans)
Automate sessions (browser and mobile)	✅ Everyone's in the organization	✅ Everyone's in the organization	Only sessions they started
Live sessions	Only their own	Only their own	Only their own
Visual projects and builds	✅ All in the organization	✅ All in the organization	✅ All in the organization

Key Points

Owner is determined by who created the organization — not by a role field
There is exactly one Owner per organization
Admins can do everything except delete the organization, manage billing, remove a member, cancel a pending invitation, and transfer ownership. Admins can resend an invitation — cancelling one is the same action as removing a user, and that is owner-only
Owner and Admin have implicit access to ALL TMT projects — they don't need to be explicitly added as project members
Automate: Owners and Admins see every session in the organization, including its video and logs. A Member sees only the sessions they started.
Live: everyone — Owner included — sees only their own Live sessions.
Visual: there are no roles. Everyone in the organization sees the same projects and builds, and can approve changes or delete a project.

Project Roles (Test Management only)

Project roles control what a user can do within a specific TMT project.

Role	Access
Project Admin	Full project access. Can manage permissions and settings.
User	Standard access. Permissions configurable by project admin.
Guest	Read-only access. Cannot modify test cases, cycles, or plans.

Who Gets Which Project Role

User	How They Get Project Access
Owner	Implicit full access to all projects (no project_members entry needed)
Admin	Implicit full access to all projects (no project_members entry needed)
Member	Must be explicitly added to each project with a role (Project Admin / User / Guest)

Implicit vs Explicit Project Membership

Implicit: Owner and Admin can access any project without being added to the project's member list. They don't show in the project's team members or assignee dropdowns unless explicitly added.
Explicit: Regular members must be added to a project. They show in team member lists and can be assigned test cases.

If you want an Owner or Admin to appear in a project's team member list (e.g., for test case assignment), you can explicitly add them via the Manage Members modal. They can only be assigned the Project Admin role.

Behind the scenes an implicit membership is still a real membership record, and two things follow from that:

Promoting someone to Admin adds them to every existing project as an implicit Project Admin, and creating a new project adds every current Admin to it the same way. You never have to add them, and you will not see them listed.
Demoting an Admin back to Member removes only the implicit records. Any project they had been explicitly added to survives the demotion, so a demoted Admin keeps access to those projects. If you are demoting someone in order to take access away, check their explicit project memberships as well.

Promoting a Member can permanently change their project role. If someone is explicitly on a project as a User or a Guest and you promote them to organization Admin, that existing record is upgraded to Project Admin. Demoting them later removes the implicit records but does not undo the upgrade — they remain a Project Admin on that project. Set the project role back by hand if that is not what you intended.

Permission Customization

For the User role, project-level permissions are customizable. A Project Admin or Owner can enable/disable specific actions per project:

Create/edit/delete test cases
Create/edit test cycles
Import/export
Manage folders
And more...

Owner, Admin, and Project Admin permissions are fixed and cannot be customized. Guest is always read-only.