Granular roles and permissions

Granular permissions let you set fine-grained access controls for the entities in your Feature Experimentation 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

The project role sets the default permissions for flags and environments, but these defaults can be overridden by specific flag or environment roles.

• 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 using Opti ID. See the
  Opti ID user documentation.

• Entities – The "things" within a project. For example:
  • Flags
  • Environments
  • Experiments
  • Multi-armed bandit optimizations
  • 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. You can adjust the default entity role 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.

Every collaborator starts with a project role, which sets their initial permissions for all entities within the project. This is the baseline, more granular control is possible through flag and environment roles.

Configure environment roles

Environment roles

You can assign the following environment roles to 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.

📘

Note

While the project role provides a default, any adjustments made at the environment or flag level takes precedence.

Update an environment role

1. Go to Settings > Environments.

   

2. For the desired environment, click More Options (...) > 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

You can assign the following flag roles to 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 unpublished rules in a specific environment.

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

📘

Note

While the project role provides a default, any adjustments made at the environment or flag level takes precedence.

Update a flag role

1. Go to Flags > Overview.

2. For the flag you want to update, click More Options (...) > 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.

The following permission matrix outlines how different combinations of environment and flag roles influence what actions you can take within a ruleset.

Choose a project role

Project role – Viewer

The Viewer role lets you view flags across all environments (Production, Staging, Development) but does not grant any edit or publish permissions. Viewers can also see which audiences (iOS Users, Android Users, Credit Card Holders) and events (Pre-Approval Start, Pre-Approval Submitted, Application Submitted) are associated with these flags.

Project role – Editor

The Editor role lets you edit flags in all environments and, in some cases, also lets you publish, depending on the specific flag settings. Editors can modify which audiences are targeted and can also manage events related to flags.

Project role – Publisher

The Publisher role lets you publish features across all environments with the ability to edit if not restricted, ensuring updates are visible to the intended audiences. Publishers can manage events.

Project role – Project owner

The Project owner role lets you publish and edit flags and manage permissions. Project owners can manage events.

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 Opti ID to log in to 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 to let them 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.

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. To let users 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 your team’s flags
• Suggested project role – Viewer
• Suggested granular permissions – Editor flag role + Editor or 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. You should set their environment roles to the appropriate level after adding them to the project.