User Roles

Learn about the different roles within OpsLevel, including basic role-based access control (RBAC) for creating and editing Service Maturity checks and campaigns.

User Roles in OpsLevel

In OpsLevel, users must be assigned to a role, which determines what actions they are permitted to take. Roles include Admin, Standards Admin, User, and Team Member.

At a high level, here's what each role can access in OpsLevel:

  • Admin: Can modify everything within the portal
  • Standards Admin: Can create Scorecards, Rubrics, Checks, and Campaigns
  • User: Can modify all service and team metadata
  • Team Member: Can only modify the services they own

The new Team Member role explained

Team Members are restricted to actions on catalog items their teams own or unowned items.

  • On a Team That Owns a Service? You can edit it.
  • Not on a Team That Owns a Service? You can’t edit it.

This authorization scheme respects the recursive nature of teams.  If you’re a member of a parent team, you can edit services owned by any child team. For example, if you're a member of the Platform Team, which is a parent team to the API Team, you are able to modify services owned by both the Platform and API teams. However, if you are only a member of the API Team, you can't make changes to services owned by the Platform Team.

The difference between an Admin and Standards Admin

Admins have full access throughout the application, while Standards Admins have edit access on Standards-related items (Rubric, Checks, etc.) but not application settings.

Admins have some additional permissions compared to Users and Standards Admins. These permissions include:

  • User management. Admins can invite, remove, and edit users and log out other users.
  • Account-wide settings. Admins can edit account-wide settings such as Tiers and Lifecycles. They can also view the plan and current usage for the organization and configure Single Sign-On.
  • Check permissions. Admins and Standards Admins have full permissions when making Check or Rubric-related changes, while other roles have read-only permissions. Refer to the Check Related Permissions section for a full breakdown of the difference between roles.
  • API tokens. Admins can create tokens with write access for our GraphQL API while other roles can only create tokens with read-only permissions.

The Users page shows all users' roles. It contains a list of all users in your account and their assigned roles. Admins can perform specific actions on the Users page, such as inviting new users, modifying the roles of existing users, and removing other users.

Viewing users as an admin

Check Related Permissions

Admins and Standards Admins have full write permissions for Check and Rubric-related features, while Users and Team Members will have read-only permissions. This includes restrictions on creating, updating, or deleting Checks, Filters, Campaigns, Categories & Levels, and updating the Rubric. Depending on your account configuration, Scorecards may be modifiable by all users (if they do not roll up to the Rubric). You can see your current role and the difference in permissions between roles on the Roles & Permissions settings page.

Note:The read-only permissions also extend to our GraphQL API. The mutations for these Check-related objects follow the same permissions specified in the above tables.

SCIM/SSO Default User Role

By default, users provisioned automatically through SCIM or SSO will receive the Team Member role. This setting can be modified on the Roles & Permissions page:

Roles & Permission setting for default user role.