Granular roles and permissions

👍

Beta

Granular permissions for flags and environments are in beta. Apply on the Optimizely beta signup page or contact your Customer Success Manager.

Granular permissions let you set more fine-grained controls than the default project roles provide. This gives you precise control over entities within your project. This is especially useful if you have multiple teams working on the same project and want to enforce specific access policies.

With granular permissions, you can:

• Limit who can change your production environment while being less restrictive in lower environments.
• Ensure collaborators can only edit flags related to their team.
• Limit visibility to flags entirely for sensitive use cases.

Key concepts

• Project Role – Every collaborator is assigned a project role. This gives them access to the project and provides a default permission level for all entities within the project.

  📘

  Note

  If your organization migrated to Opti ID, you must manage users in Opti ID. See the
  Opti ID user documentation.

• Entities – The "things" within a project. For example:
  • Flags
  • Environments
  • Experiments
  • Multi-armed bandit optimization
  • Targeted deliveries
  • Audiences
  • Events
• Entity Role – Roles assigned to collaborators for an individual entity. A collaborator's project role is their starting point for entities, providing a default entity role. The default entity role can be adjusted higher or lower to give collaborators within the project the desired access.

📘

Note

By default, account Admins and Project Owners can change the entity-level permissions for another user. If they make that user an Admin for a specific entity, then that user can also manage permissions for that entity.

Configure environment roles

Environment roles

The following environment roles are available to assign a user:

Admin

• Can modify other users' environment permissions.
• Plus all Publisher permissions.

Publisher

• Can publish or edit all flag rules in the environment.*
• Plus all Editor permissions.

Editor

• Can edit non-published flag rules in the environment.*
• Plus all Viewer permissions.

Viewer

• Can view the environment and its settings.
• Can view flag rules within the environment.**

* Must also have an Editor flag role to publish or edit a flag’s rules.
** Must also have a Viewer flag role to view a flag’s rules.

Update an environment role

1. Go to Settings > Environments.

   

2. For the desired environment, click More and select Manage Permissions.

   

3. (Optional) Search for the desired user.

4. Click Edit.

   

5. Select the updated Environment Role.

6. Click Save.

   

Configure flag roles

Flag roles

The following flag roles are available to assign a user:

Admin

• Can modify other users flag permissions.
• Plus all Editor permissions.

Editor

• Can publish rules or edit published rules.*
• Can edit unpublished flag rules.**
• Can create variables, variations, and adjust flag settings.***
• Plus all Viewer permissions.

Viewer

• Can access the flag and view its contents.***

None

• Can not view the flag or its contents

* Must also have a Publisher environment role to publish rules or edit published rules in a specific environment.

** Must also have an Editor environment role to edit un-published rules in a specific environment

*** Must also have a Viewer environment role to view rules in a specific environment.

Update a flag role

1. Go to Flags > Overview.

2. For the flag you want to update, click More and select Manage Permissions.

3. (Optional) Search for the desired user.

4. Click Edit.

   

5. Select the updated Flag Role.

6. Click Save.

   

Interaction between flag and environment roles

Understanding Feature Experimentation projects, entities, and the relationship between flags and environments is helpful when configuring granular permissions.

Each flag rule runs in a specific environment, and the flag’s collection of rules in an environment is called a ruleset. When using granular permissions, the lower role between the flag and environment determines what a user can do within a ruleset.

The following diagram shows example flag and environment role combinations, along with the resulting ruleset permissions where each flag and environment intersect:

📘

Note

The maximum permission in a ruleset is Publisher. An entity Admin can manage permissions for that entity but is still considered at most a Publisher within a ruleset

Common Use Cases

Here are some common granular permission use cases and how to configure your project and entity roles to achieve your desired workflow.

📘

Note

The following are for users who do not use OptID to login into Optimizely.

You should first consider different ways to add new collaborators to a project. Because a collaborator’s project role provides a starting point for all flag and environment roles, one strategy may better fit your desired use case:

• Edit access by default – Using the Editor project role, new users can view all flags and edit unpublished rules by default. They cannot publish rules in production but can in non-production environments. You must grant higher access if they can publish rules in production.
• View access by default – Using the Viewer project role, new users can view all flags and their rules in all environments by default. You must explicitly grant higher access to flags and environments they should be able to edit in.
• No access by default – Using the Limited Access project role, new users can’t access any flags by default and have view access in all environments. You must explicitly grant access to individual flags and environments.

Use Case: Restrict publishing in production

• Objective – Restrict who can publish or make changes to flags in production
• Suggested project role– Editor
• Suggested granular permissions – Publisher environment role

When adding new collaborators as Editor, by default, they can create, edit, and publish rules in non-production environments. In production, they cannot publish a flag or edit published rules. For users you want to be able to publish in production, elevate their environment role to Publisher.

Use Case: Avoid inadvertent flag changes from other teams

• Objective – Avoid other collaborators inadvertently making a change to my team’s flags
• Suggested project role – Viewer
• Suggested granular permissions – Editor flag role + Editor/Publisher environment roles

Adding new collaborators as Viewer gives you more explicit control over who can edit each flag. When creating a new flag, elevate the specific collaborator's flag role to Editor so they can make changes.

📘

Note

Adding a user as a Viewer to the project means they have view-only permissions for all environments. It’s recommended to set their environment roles to the appropriate level after adding them to the project.

FAQ

Question: What happens if I set a granular permission that conflicts with my project role?

The granular permission takes precedence. For example, if you are a Viewer at the project level but are set as an Editor for a specific flag, your Editor permissions for that flag apply.