Users & Permissions

Testmo comes with flexible user management and customizable user, group & project permissions so you can easily add your team, grant access to specific projects and invite external collaborators to work on your software tests. This page explains how to best manage users and how to benefit from Testmo's roles & permissions.
User authentication and integration
If you are interested in how users can log in to and authenticate with Testmo, and how you can use authentication integrations to easily invite a large number of users, see our Authentication article.
User management
In addition to groups, roles and permissions, Testmo supports different types of users so you can assign different levels of administration access and optimize subscription usage. Here's the list of user types supported by Testmo:
Regular user
Most users in your Testmo instance are usually regular users. They have access to your projects (based on assigned permissions) but don't have access to the Admin section.
Viewer
Viewer users are a special user type supported by some subscription add-ons. The difference to Regular Users is that they are not counted toward the subscription user count. They also always only have read-only access. This user type is useful to invite a larger number of users to your projects who don't need to contribute any test results and to save on subscription fees. Note: it is important to assign the Viewer user type to users to make sure users are not counted; this is not the same as assigning read-only permissions.
Project admin
Project admins also have access to a subset of the Admin section. They can manage projects, fields, statues, configurations etc. (all sections grouped under the Management section of the Admin area). This is useful if you want to grant limited admin access to some project managers, for example. Important: project admins can still do a lot of damage to your configuration, as they have full access to manage (and delete) custom fields, integrations, workflows etc. So make sure to only assign this user type to users who know what they are doing.
Site admin
Site admins can access the entire Admin section of your Testmo instance. So in addition to the areas accessible by project admins, they can also add and manage users, change authentication options, review the audit log and subscription status, as well as access data exports and the site settings.
API user
API users are a special user type supported by some subscription plans. API users can be used to create separate service or machine/host accounts to for integrations such as automation. They are not counted for the subscription user count and API users cannot login to the user interface. Note: you can still use the full API and automation features without API users, see below.
You can still use automation & the API without API users
API users are useful if you want to create separate service or machine accounts for specific integrations or hosts. But you can still use the full automation & API features without API users. Instead of creating separate API users, you simply add API keys to your normal user accounts.
Roles, groups & permissions
Testmo comes with flexible options to make sure that users can only access the features and projects they should have access to. This section explains the different ways you can assign permissions and configure projects to accomplish this.
Global user roles
Every user in Testmo has an assigned global role. A role is a selection of permissions and you can change or add new roles under Admin > Users & Roles. If a user is in no additional groups, and you haven't assigned a project-level role, by default the global role of a user is used for all projects (unless you change the project configuration, see below).
For example, if a user should only be able to add test results but not create any test cases, you would assign them the default role Tester.
Roles can be used for users, groups & in projects
Groups
Users can optionally be assigned to one or more groups. For example, you could create a group for a certain team, for a certain customer or for a specific department in your organization. You can then use the group to assign project-level access (see below), making it easy to grant specific project access to a larger number of users at once without having to manage each individual user's permissions.
If a user is assigned to more than one group, or the user itself has higher project permissions, then the highest (combined) permissions are used for a user.
Project access
By default, new projects are configured to use the global roles for users. This can be changed when you edit a project and change the Default access option. For example, you could change the default access to No access instead of Global role, so users cannot access nor see the project unless they are assigned project-level permissions (either directly or via a group).
Instead of Global role or No access you can also select a specific role as the project default. This way you could e.g. make a project read-only for all users, unless they are assigned project-level permissions (either directly or via a group).
When you edit a project, you can assign user-level and group-level permissions from the Users and Groups tabs. This way you can override the project default. See below for examples on how to use this feature to implement certain scenarios.
Configuring project-level access
Restricted fields
Sometimes it can be useful to use custom fields with restrictions for some users. For example, if you add a Review dropdown field to select if a test case needs a review or has been reviewed, you might want to restrict this field to test leads or managers. This way most users cannot change this field unless they have the permission to do so.
How restricted fields work: when you create or edit a custom field and then assign it to one or more projects, you can select whether everyone can update this field or that only users with restricted field permissions can do so. Only users with the relevant permissions for a project can then update this field:
Cases (restricted fields)
Run results (restricted fields)
Sessions (restricted fields)
Recipes and examples
In this section we will look at a few concrete examples on how to use Testmo's permissions and roles to implement certain scenarios. Let us know if you are unsure on how to implement certain permissions and we are happy to add more examples here.
Making entire projects read-only
If you would like to make an entire project read-only, for example to archive it, you can easily do so by editing the project and changing the Default access option to the Read-only role. Important: make sure that there aren't any additional user or group overrides for the project by reviewing its Users and Groups tabs. If you want to ensure that all users can't edit a project anymore, also remove any overrides on these tabs.
Hiding projects from all or some users
If you would like to hide a project from all or some users, simply edit the project and change the Default access option to No access. Only users (either directly or through a group) with additional project permissions can access the project now.
Make sure to review the project's Users and Groups tabs to add or remove any exceptions. This way you can make sure that no user can access the project, or you can grant certain users or groups additional access.
Allowing project access to certain user groups only
The easiest way to ensure that only certain groups can access a project is to change the Default access option of a project to No access. Then, to grant certain users or groups access to the project, add exceptions from the Users and Groups tabs of the project's edit dialog. For example, you could select Global role for the project access column next to certain groups, ensuring that users in this group can see and access the project with their normal global user role.
Ensuring new projects follow your policy
By default, new projects are created with the Default access of Global role. If you would like to make it easier for your admins to create new projects with a different default, such as No access or Read-only, simply change the default by clicking Default access from the Admin > Projects page.