--- title: Granular roles and permissions in Feature Experimentation slug: feature-experimentation/docs/granular-roles-and-permissions-in-feature-experimentation docTags: createdAt: 2026-08-05T20:39:58.000Z --- - Optimizely Feature Experimentation 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](docId\:bNAxj4srKHVczBp27i1DH). :::hint{type="info"} **Note** If your organization migrated to Opti ID, you must manage users using Opti ID. See the [Opti ID user documentation](docId\:gfcl33i3WnqFAwFi9CT6y). ::: - **Entities** – The parts of a project. For example, - [Flags](docId\:eH-UMm_rOn_GdGDGLV6__) - [Environments](docId\:YpSOMYlWkUccLCL-uB-ZE) - [Audiences](docId\:UDBvr5a8WHNkyOqzPhOr9) - [A/B tests](docId:8pnfCv-sR37goLcxTtCPv) - [Multi-armed bandit optimizations](docId\:F5-ZUIoxCu2_XRy26tO-b) - [Targeted deliveries (flag delivery)](docId:_BjMxuGwwlVrhkNcx2kzm) - [Events](docId:3kGIZlCkODJIOJuT3bdWo) - **Entity role** – Grants access to a specific entity. You can increase or decrease a collaborator's entity role to control what they can do. :::hint{type="info"} **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](docId\:bNAxj4srKHVczBp27i1DH) or [Manage roles and permissions](docId\:kwj5GClJJTxjDSdDQSd-o) 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](docId\:a8Lou8ccOZnqTR863LJGo) – Overrides default access in specific environments. - [Flag roles](docId\:F8tdFPnxECabBXsQkBqDt) – Controls access to individual flags. - [Audience roles](docId\:aG4JyFgVeCLJsPnBhfUTX) – 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](docId\:YpSOMYlWkUccLCL-uB-ZE) (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. ![db54003-Project\_Role\_Viewer.png](https://api.archbee.com/api/optimize/BrbvVORKJ5iIeSMZye5kI/QDd5rVWoVoalN-ERFkhJA-20260720-145802.png) :::hint{type="info"} **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](docId\:LOdWB2Hydyy3zwzwFOTTz). ::: ### 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. ![f159a07-Project\_Role\_Editor\_.png](https://api.archbee.com/api/optimize/BrbvVORKJ5iIeSMZye5kI/d5frxrXHCADPeZfGgMIYw-20260720-145802.png) ### 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. ![22b8526-Granular\_roles\_permissions\_-\_Project\_Role\_\_Publisher.png](https://api.archbee.com/api/optimize/BrbvVORKJ5iIeSMZye5kI/GtSTK0O2oP86Hz_-7QSpp-20260720-145802.png) ### Project role – Project owner The **Project owner** role lets you publish and edit flags and manage permissions. Project owners can manage events. ![ac0fe25-Project\_Role\_Project\_Owner.png](https://api.archbee.com/api/optimize/BrbvVORKJ5iIeSMZye5kI/9ywFQ3zSmxlr2_aaKOXlI-20260720-145801.png) ## 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 :::hint{type="info"} **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. :::hint{type="info"} **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](docId:4OlvMcsnIe7HXXPBMxFqJ). ## Manage permissions ### Environment and flag roles Before assigning environment or flag roles, [see how these roles interact](docId\:AzOxmAb1cxMjH_S5Tbgyj). Then, use the following documentation to manage granular access by entity type: - [Manage environment roles](docId\:a8Lou8ccOZnqTR863LJGo) – Grant or change a collaborator's access in a specific environment. - [Manage flag roles](docId\:F8tdFPnxECabBXsQkBqDt) – 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. \ See [Manage audience roles](docId\:aG4JyFgVeCLJsPnBhfUTX) to control who can view, edit, or manage access to a specific audience.