Granular roles and permissions

Granular roles and permissions let you control access to environments, flags, and audiences with precision. Instead of relying only on project-level roles, you can grant more specific access, making it easier to give teammates the exact access they need.

Key concepts

To give a collaborator access to your project, assign them a project role. This sets their initial level of access to all project entities. You can then use granular permissions to fine-tune that access at the environment, flag, or audience level.

• Project role – Provides access to the project and sets a default permission level for entities within it. You assign project roles in Settings > Collaborators.

  📘

  Note

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

• Entities – The parts of a project. For example,
  • Flags
  • Environments
  • Audiences
  • A/B tests
  • Multi-armed bandit optimizations
  • Targeted deliveries (flag delivery)
  • Events
• Entity role – Grants access to a specific entity. You can increase or decrease a collaborator's entity role to control what they can do.

  📘

  Note

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

  See Collaborators or Manage roles and permissions if your organization migrated to Opti ID.

Role overview

Granular permissions apply across four levels:

• Project roles – Sets a collaborator's default access across a project.
• Environment roles – Overrides default access in specific environments.
• Flag roles – Controls access to individual flags.
• Audience roles – Controls access to individual audiences.

These roles build on one another. If a collaborator has different permissions at multiple levels, the most specific one (like a flag or audience role) takes precedence.

Choose a project role

The examples in the following sections use a sample set of project roles to show how different permissions work. Use these examples to understand how project roles relate to the environment and flag roles when assigning access in your own Feature Experimentation project.

Project role – Viewer

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

📘

Note

Viewers cannot create flags or audiences unless they have Editor or Admin access in at least one environment. For details, see Flag and audience creation behavior.

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.

Use cases

You can enforce specific entity access policies for multiple teams working on the same Feature Experimentation project. For example, you can do the following:

• Determine who can change your production environment while being less restrictive in lower environments.
• Ensure collaborators can edit flags that are only related to their team.
• Determine flag visibility for sensitive use cases.
• Restrict changes to shared audiences.
• Create teams to manage permissions in groups of collaborators.

Common configurations

📘

Note

The following example configurations are for collaborators who do not use Opti ID to log in to Optimizely.

You should first consider different ways to add collaborators to a project. A collaborator's project role provides a starting point for flag and environment roles, so one strategy may better fit your use case.

• Edit access by default – Using the Editor project role, new collaborators can view flags and edit unpublished rules by default. They can publish rules in non-production environments, but you must grant higher access to let them publish rules in production.
• View access by default – Using the Viewer project role, new collaborators can view flags and their rules in environments by default. You must explicitly grant higher access to flags and environments they should be able to edit in.

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.

Adding collaborators as Editor lets them create, edit, and publish rules in non-production environments. In production, they cannot publish a flag or edit published rules unless you elevate their environment role to Publisher.

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 collaborators as Viewer gives you more explicit control over who can edit each flag. When creating a flag, elevate the specific collaborator's flag role to Editor so they can make changes.

📘

Note

Adding a collaborator as a Viewer to the project means they have view-only permissions for all environments. You should configure their environment roles to the appropriate level after adding them to the project.

Teams

You can create teams to manage granular permissions for entities in bulk. Grouping collaborators into a team automatically applies assigned permissions to all members, simplifying onboarding and adjustments.

See Configure teams.

Manage permissions

Environment and flag roles

Before assigning environment or flag roles, see how these roles interact. Then, use the following documentation to manage granular access by entity type:

• Manage environment roles – Grant or change a collaborator's access in a specific environment.
• Manage flag roles – Control who can view, edit, or manage access to a specific flag.

Flag and audience creation behavior

When a collaborator creates a flag or an audience, Feature Experimentation automatically assigns them the Admin role for that flag or audience using granular permissions. This ensures the creator can immediately manage access without needing additional configuration.

To create a flag or audience, a collaborator must have Editor or Admin access in at least one environment. For example, a collaborator with the Viewer project role can still create flags or audiences if they have been granted elevated environment-level permissions.

📘

Note

If your project does not use granular permissions, the collaborator must have the Editor or Admin project role to create flags or audiences.

See Manage audience roles to control who can view, edit, or manage access to a specific audience.