> ## Documentation Index
> Fetch the complete documentation index at: https://launchdarkly-preview.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Example roles and policies

> This topic shows some examples of different roles and policies you can implement with policy statements for roles, integrations access, and Relay Proxy access.

> For the complete documentation index, see [llms.txt](/llms.txt). For the full documentation snapshot, see [llms-full.txt](/llms-full.txt).

## Overview

This topic shows some examples of different roles and policies you can implement with policy statements for roles, integrations access, and Relay Proxy access.

LaunchDarkly provides several preset roles which include access to common sets of features. Customers on select plans can update these presets or create their own roles. If you are looking for example roles or policies, we recommend that you start by examining the preset organization and project roles provided by LaunchDarkly. You can also add policy statements to these roles, if the permissions they provide are not quite what works best for your organization. To learn more, read [Member role concepts](/home/account/roles/role-concepts), [Organization roles](/home/account/roles/organization-roles), and [Project roles](/home/account/roles/project-roles).

## Role examples

Use these sets of policy statements as a starting point for creating or updating roles in your account.

### Example: View-specific permissions

<Accordion title="Expand Example: View-specific permissions">
  One way to organize access to flags is by adding flags to a [view](/home/getting-started/vocabulary#view), which is a resource to logically group flags within a project. For example, you can create "frontend" and "backend" views to organize flags within your project, and separate access to flags in those views.

  This policy allows access to all actions on flags in the "frontend" view in the "default" project. You can copy and modify this example to suit your needs:

  <CodeGroup>
    ```json title="Allow access to flags in the "frontend" view" theme={null}
          [
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/default:env/*:flag/*;view:frontend"]
            }
          ]
    ```
  </CodeGroup>

  You can also modify this policy to specify the project and view using [role attributes](/home/account/roles/role-scope). This means you can reuse this role for different members working on different projects and views:

  <CodeGroup>
    ```json title="Allow access to flags in views specified by the "viewKey" role attribute" theme={null}
          [
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/${roleAttribute/projectKey}:env/*:flag/*;view:${roleAttribute/viewKey}"]
            }
          ]
    ```
  </CodeGroup>

  In some cases, policies in which you specify the view using role attributes can only be created in the [advanced editor](/home/account/roles/advanced-editor). To learn more, read [Use views in complex policy statements](/home/account/roles/role-scope#use-views-in-complex-policy-statements).

  If you use views to restrict access to sets of flags, it may be helpful to require that flags are associated with a view. One way to enforce this is to create a role that only allows the `createFlag` action within a particular view. For example, if you normally restrict flag creation to certain roles, you could update the policy statements for those roles to include a specific view.

  Here's how:

  <CodeGroup>
    ```json title="Only allow flag creation in the "frontend" view" theme={null}
          [
            {
              "effect": "allow",
              "actions": ["createFlag"],
              "resources": ["proj/default:env/*:flag/*;view:frontend"]
            }
          ]
    ```
  </CodeGroup>

  When a member creates a feature flag, they can associate it with multiple views in a single request. A `createFlag` statement scoped to one view does not prevent a member from listing additional views in the same API call. This means that a member may be able to add a flag to a view that they do not have access to, as long as they are also adding it to a view they do have permission to add flags to. Access to the flag after it exists is still governed by your other policy statements.

  To learn more about views, read [Views](/home/account/views).
</Accordion>

### Example: Deny bypassing approvals in critical environments

<Accordion title="Expand Example: Deny bypassing approvals in critical environments">
  This example policy uses the `{property:value}` pattern to deny actions on environments based on whether or not they are [critical environments](/home/account/environment#critical-environments). You can mark any environment as critical when you create or update it. Production environments default to being marked as critical.

  To manage environments based on the `critical` property, you must specify the property-based selector as part of the modifiers for the environment resource. Limiting `resources` to `"proj/*:env/*;{critical:true}"` accomplishes this.

  Copy this policy and make any modifications to it to suit your needs:

  <CodeGroup>
    ```json title="Deny bypassing approvals in critical environments" theme={null}
          [
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/*:env/*:flag/*"]
            },
            {
              "effect": "deny",
              "actions": ["bypassRequiredApproval"],
              "resources": ["proj/*:env/*;{critical:true}:flag/*"]
            }
          ]
    ```
  </CodeGroup>
</Accordion>

### Example: Grant access to flag toggles, but not flag rollout or targeting rules

<Accordion title="Expand Example: Grant access to flag toggles, but not flag rollout or targeting rules">
  This example policy allows members of the Ops team to toggle on or off any flags in the production environment. They may not change percentage rollouts or targeting rules, or manage any environments or projects.

  Copy this policy and make any modifications to it to suit your needs:

  <CodeGroup>
    ```json title="Ops team" theme={null}
          [
            {
              "effect": "allow",
              "actions": ["updateOn"],
              "resources": ["proj/*:env/production:flag/*"]
            }
          ]
    ```
  </CodeGroup>
</Accordion>

### Example: Grant all actions to just one flag

<Accordion title="Expand Example: Grant all actions to just one flag">
  The policy below allows all actions to be done to a single specified flag, `flag-1`.

  For a complete list of flag actions, read [Feature flag actions](/home/account/roles/role-actions#feature-flag-actions).

  Copy this policy and make any modifications to it to suit your needs:

  <CodeGroup>
    ```json title="One flag" theme={null}
          [
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/*:env/*:flag/flag-1"]
            }
          ]
    ```
  </CodeGroup>
</Accordion>

### Example: Grant all actions to just one flag while showing only one project

<Accordion title="Expand Example: Grant all actions to just one flag while showing only one project">
  The policy below allows access only to a project a flag is in, and allows you to perform actions on that flag. In this example, both the project and the flag are specified using [role attributes](/home/account/roles/role-scope). When you assign this role to a member or team, you are prompted to fill in the `projectKey` and `flagKey` referenced in this role. This means you can reuse this role for different members working on different projects and flags.

  Copy this policy and make any modifications to it to suit your needs:

  <CodeGroup>
    ```json title="One flag" theme={null}
          [
            {
              "effect": "allow",
              "actions": ["viewProject"],
              "resources": ["proj/${roleAttribute/projectKey}"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/${roleAttribute/projectKey}:env/*:flag/${roleAttribute/flagKey}"]
            }
          ]
    ```
  </CodeGroup>
</Accordion>

### Example: Restrict actions within production environments

<Accordion title="Expand Example: Restrict actions within production environments">
  This policy allows using only these actions in the `production` environment:

  * `updateFlagVariations`
  * `updateTags`

  This means you can take all other actions in any other non-production environment. In this example, the environment is set to the `production` environment, but the project is specified using a [role attribute](/home/account/roles/role-scope). When you assign this role to a member or team, you are prompted to fill in the `projectKey` referenced in this role. This means you can reuse this role for different members working on different projects.

  Copy this policy and make any modifications to it to suit your needs:

  <CodeGroup>
    ```json title="Non-prod environments" theme={null}
          [
            {
              "effect": "allow",
              "actions": ["viewProject"],
              "resources": ["proj/${roleAttribute/projectKey}"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/${roleAttribute/projectKey}:env/*:flag/*"]
            },
            {
              "effect": "deny",
              "notActions": [
                "updateFlagVariations",
                "updateTags"
                ],
              "resources": ["proj/${roleAttribute/projectKey}:env/production:flag/*"]
            }
          ]
    ```
  </CodeGroup>
</Accordion>

### Example: Allow access to flags, metrics, and segments in one project

<Accordion title="Expand Example: Allow access to flags, metrics, and segments in one project">
  In this example, the policy allows specific flag actions in one project, all segment actions in all projects, and all metric actions in all projects. The particular project is specified using a [role attribute](/home/account/roles/role-scope). When you assign this role to a member or team, you are prompted to fill in the `projectKey` referenced in this role.

  Copy this policy and make any modifications to it to suit your needs:

  <CodeGroup>
    ```json title="Flags, metrics, and segments" theme={null}
          [
            {
              "effect": "allow",
              "notActions": [
                "createFlag",
                "updateTargets",
                "updateRules",
                "createExperiment",
                "deleteExperiment",
                "updateScheduledChanges"
              ],
              "resources": ["proj/${roleAttribute/projectKey}:env/*:flag/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/*:env/*:segment/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/*:metric/*"]
            }
          ]
    ```
  </CodeGroup>
</Accordion>

### Example: Deny access to the production environment

<Accordion title="Expand Example: Deny access to the production environment">
  In the next example, the environment key `production` represents the account's production environment in all projects. This policy denies the member from modifying any feature flags in production:

  <CodeGroup>
    ```json title="Statement" theme={null}
          [
            {
              "effect": "deny",
              "actions": ["*"],
              "resources": ["proj/*:env/production:flag/*"]
            }
          ]
    ```
  </CodeGroup>

  You can also name an "inverse" set of resources by using `notResources` in a statement. `notResources` explicitly allows all actions to feature flags across all environments *except* an environment you specify.

  In the example below, the combination of `notResources` and the `allow` effect gives access to all environments *except* the production environment.

  Here's how:

  <CodeGroup>
    ```json title="notResources statement" theme={null}
          [
            {
              "effect": "allow",
              "actions": ["*"],
              "notResources": ["proj/*:env/production:flag/*"]
            }
          ]
    ```
  </CodeGroup>
</Accordion>

## Base role templates

Unlike the LaunchDarkly-provided [preset roles](/home/getting-started/vocabulary#preset-roles), you cannot edit or view policy details of the base roles in the LaunchDarkly user interface. The sections below show the policy details for these roles. You can copy and modify these Reader, Writer, Admin, and No access role templates for your own roles if needed.

### Reader role

<Accordion title="Expand Reader role">
  Copy this Reader base role and make any modifications to it to suit your needs:

  <CodeGroup>
    ```json title="Reader role" theme={null}
          [
            {
              "effect": "allow",
              "actions": ["viewProject"],
              "resources": ["proj/*"]
            },
            {
              "effect": "allow",
              "actions": ["createAccessToken"],
              "resources": ["member/*:token/*"]
            }
          ]
    ```
  </CodeGroup>
</Accordion>

### Writer role

<Accordion title="Expand Writer role">
  Because permissions are set to `deny` by default, you must explicitly allow actions for the Writer role. The code snippet below is a replication of LaunchDarkly's Writer base role. You can copy it and make adjustments as needed.

  Copy this Writer base role and make any modifications to it to suit your needs:

  <CodeGroup>
    ```json title="Writer role" theme={null}
          [
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["application/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["code-reference-repository/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["integration/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["member/*:token/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": [
                "proj/*:env/*:aiconfig/*"
              ]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/*:env/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/*:env/*:destination/*"]
            },
              {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/*:env/*:experiment/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/*:env/*:flag/*"]
            },
            {
              "effect": "deny",
              "actions": ["bypassRequiredApproval"],
              "resources": ["proj/*:env/*:flag/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/*:env/*:holdout/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/*:env/*:segment/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/*:layer/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/*:metric/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/*:metric-group/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/*:view/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["relay-proxy-config/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/*:release-policy/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["service-token/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["template/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["webhook/*"]
            }
          ]
    ```
  </CodeGroup>
</Accordion>

### Admin Role

<Accordion title="Expand Admin role">
  Because permissions are set to `deny` by default, you must explicitly allow actions for the Admin role. The code snippet below is a replication of LaunchDarkly's Admin base role. You can copy it and make adjustments as needed.

  Copy this Admin base role and make any modifications to it to suit your needs:

  <CodeGroup>
    ```json title="Admin role" theme={null}

          [
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["acct"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["application/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["code-reference-repository/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["domain-verification/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["integration/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["member/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["member/*:token/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["pending-request/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/*:env/*:aiconfig/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/*:context-kind/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/*:env/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/*:env/*:destination/*"]
            },
              {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/*:env/*:experiment/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/*:env/*:flag/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/*:env/*:holdout/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/*:env/*:segment/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/*:layer/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/*:metric/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/*:metric-group/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/*:view/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/*:release-pipeline/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["proj/*:release-policy/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["member/*:token/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["relay-proxy-config/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["role/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["service-token/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["team/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["template/*"]
            },
            {
              "effect": "allow",
              "actions": ["*"],
              "resources": ["webhook/*"]
            }
          ]
    ```
  </CodeGroup>
</Accordion>

### No access role

<Accordion title="Expand No access role">
  Permissions are set to `deny` by default. In other words, by default roles cannot take any actions on any resources. You must create a policy that provides the level of access you prefer. An empty policy is equivalent to the Member preset role or the No access base role.
</Accordion>