Disclaimer: This website requires Please enable JavaScript in your browser settings for the best experience.

The availability of features may depend on your plan type. Contact your Customer Success Manager if you have any questions.

Dev guideRecipesAPI ReferenceChangelog
Dev guideAPI ReferenceUser GuideLegal TermsGitHubDev CommunityOptimizely AcademySubmit a ticketLog In
Dev guide

Granular roles and permissions

Defines granular roles and permissions for Optimizely Feature Experimentation.

Granular permissions let you enforce specific entity access policies for multiple teams working on the same Feature Experimentation project.

With granular permissions, 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 users.

Key concepts

To access a project, assign a project role to a collaborator. This role sets the initial permissions for entities within the project. Granular permissions let you override these defaults to define custom access controls for individual entities.

  • Project role – Provides access to the project and a default permission level for entities within the project. You assign each collaborator to a project role.

📘

Note

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

📘

Note

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

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

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 – Viewer

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 – Editor

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 – Publisher

Project role – Project owner

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

Project role – Project owner

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 use cases are for users 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 users 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 users 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.

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

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.

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 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 user 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.

Manage permissions

The following documentation provides instructions on managing granular permissions for each entity.