> ## Documentation Index > Fetch the complete documentation index at: https://launchdarkly.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Using role scope This topic explains how to work with **role scope** and **role attributes**. A role scope is a [resource type](/docs/home/account/roles/role-resources) by which a role may be parameterized. When you define a role, you can optionally specify a role scope and the parameter, which is called a role attribute. If multiple members or teams should have similar permissions, but work with different resources, then defining role scope using an attribute key lets you reuse the same role for many members or teams. This means the total number of roles in your account is much smaller, and much easier to maintain. This topic includes: * [Background information on resources, role scope, and role attributes](#background-resources-role-scope-and-role-attributes) * [How to define role scope using a role attribute](#define-role-scope-using-attribute-key) * [How to set a role attribute value when you assign a role to a member or team](#set-role-attribute-values) * [Example: Consolidate existing roles using role attributes](#example-consolidate-existing-roles-using-role-attributes) ## Background: Resources, role scope, and role attributes When you create a new role, you can specify **resources** that the role can or cannot access in the following ways:
Types of resources a role can access Example
All instances of the resource. All projects
All instances of the resource with a few exceptions. All projects except "Project A"
Only specific instances of the resource, where the instances are named explicitly in the role's policy statements. "Project A," "Project B," and "Project C"
Only specific instances of the resource, where the instances are linked to a particular view. To learn more, read [Use views in complex policy statements](#use-views-in-complex-policy-statements). All flags in a project that are linked to the "frontend" view.
Only specific instances of the resource, where the instance properties match a particular value. All environments that are marked as [critical](/docs/home/account/environment#critical-environments). To learn more, read [Property-based selectors](/docs/home/account/roles/role-concepts#property-based-selectors).
Only specific instances of the resource, where the instances are specified based on a parameter. This parameter is called a [**role attribute**](/docs/home/getting-started/vocabulary#role-attribute).
In this option, you define the role attribute when you create the role, and you specify its value when you assign the role to an account member or team.
For example, you can define the role attribute as "developerProjectKeys," set the value of the role attribute to "Project A" when you assign the role to member A, and then set the value of the role attribute to "Project B" when you assign the role to member B.
This option is discussed in more detail in the sections below: [Define role scope using attribute key](#define-role-scope-using-attribute-key), [Set role attribute values](#set-role-attribute-values). 		"developerProjectKeys"
Role attributes are defined and assigned within LaunchDarkly. They cannot be passed through SAML assertions for single sign-on. For SAML-based SSO, LaunchDarkly supports mapping only the `role`, `customRole`, and `teamKey` attributes. ## Define role scope using attribute key To define role scope using a role attribute when you [create a new role policy](/docs/home/account/roles/role-create): 1. From the "New role" page, click **Role attributes** to open the "Scope using attribute key" section: The "Role attributes" section of the "New role" page. 2. Click **+ Add resource scope**. 3. Select a resource type from the menu, for example, "Project." 4. At the prompt, enter a key for the [role attribute](/docs/home/getting-started/vocabulary#role-attribute): The "developerProjectKeys" defined as a role attribute. 5. The role attribute is now a parameter for this role. 6. In the role's policy statements, use the role attribute key any place that you would normally use a specific instance of that resource. For example, if you selected the "Project" resource type in step 3, then you can use the role attribute to allow access only to projects: "developerProjectKeys" used in a policy statement. 7. Click **Create role**. You set the value of the role attribute when you assign this role to a member or team. In this example, you would enter values for one or more project keys when you assign this role. To learn how, read [Set role attribute values](#set-role-attribute-values), below. To learn more about creating roles, read [Creating roles and policies](/docs/home/account/roles/role-create). ## Set role attribute values You set a role attribute value, or specific resource, when you assign a role to an account member or team. In the "Assign access" dialog, enter the values for the role attribute in the **Resources** field: The "Assign access" dialog, with a role attribute and resource specified for the custom role being assigned. You can enter one or more values when you set the role attribute. For example, you can set the value of the role attribute to `projectA` (the project key of "Project A") when you assign the role to one member, and then set the value of the role attribute to `projectB` and `projectC` (the project keys of "Project B" and "Project C") when you assign the role to a different member. You can also use the REST API: [Custom roles](/docs/api/custom-roles). In the REST API, use the syntax `${roleAttribute/}`, for example `${roleAttribute/developerProjectKeys}`, in your policy statements. To learn more, read [Assigning roles to members](/docs/home/account/roles/manage-role-assign) and [Assigning roles to teams](/docs/home/account/roles/manage-role-team). ## Example: Consolidate existing roles using role attributes Without role scope, if you have two members who require a similar set of permissions, but require access to different flags, you need to define two roles, one for each member: ```json title="Role with access to flag-1" lines wrap theme={null} { "effect": "allow", "actions": [ "*" ], "resources": [ "proj/example-project:env/*:flag/flag-1" ] } ``` ```json title="Role with access to flag-2" lines wrap theme={null} { "effect": "allow", "actions": [ "*" ], "resources": [ "proj/example-project:env/*:flag/flag-2" ] } ``` Given additional flags, or additional projects, the number of roles required increases rapidly, and quickly becomes unmanageable. You can use role scope to define just one role. Then, you can assign the same role to both members. Here's the previous set of roles, rewritten to use the `flagKey` role attribute: ```json title="Role with access to a flag defined by role attribute" lines wrap theme={null} { "effect": "allow", "actions": [ "*" ], "resources": [ "proj/example-project:env/*:flag/${roleAttribute/flagKey}" ] } ``` When you assign this role to each member, you set the value of `flagKey` to the specific flag that that member should have access to. You can use multiple role attributes in a given role. For example, if you also wanted to parameterize the project, you could use a separate role attribute for that: ```json title="Role with access to a project and flag defined by role attribute" lines wrap theme={null} { "effect": "allow", "actions": [ "*" ], "resources": [ "proj/${roleAttribute/projectKey}:env/*:flag/${roleAttribute/flagKey}" ] } ``` In this case, LaunchDarkly prompts you to set the value of both role attributes when you assign the role to a member. For additional examples of roles defined using role attributes, read: * [Example: Grant all actions to just one flag while showing only one project](/docs/home/account/roles/example-roles#example-grant-all-actions-to-just-one-flag-while-showing-only-one-project) * [Example: Restrict actions within production environments](/docs/home/account/roles/example-roles#example-restrict-actions-within-production-environments) * [Example: Allow access to flags, metrics, and segments in one project](/docs/home/account/roles/example-roles#example-allow-access-to-flags-metrics-and-segments-in-one-project) ## Special cases for role scope For some policy statements, you may need a combination of the [advanced editor](/docs/home/account/roles/advanced-editor) and the REST API to define a policy that uses role scope or to set role attribute values. ### Use views in complex policy statements You can [define a role scope](#define-role-scope-using-attribute-key) for a [view](/docs/home/account/views) when you [create a role](/docs/home/account/roles/role-create). The [policy builder](/docs/home/account/roles/role-create#create-policies-for-roles) supports using the `viewKey` role attribute in a statement with a "view" resource scope. Here's an example policy: The policy builder, with a statement allowing access to views based on the "viewKey" role attribute. This statement allows access to all actions on the views specified by `viewKey` in the project specified by `projectKey`. In the advanced editor, the statement looks like this: ```json title="Policy allowing access to views based on 'viewKey' role attribute" lines wrap theme={null} [ { "effect": "allow", "actions": ["*"], "resources": [ "proj/${roleAttribute/projectKey}:view/${roleAttribute/viewKey}" ] } ] ``` You can also use a view role attribute in a flag scope statement. Here's an example: ```json title="Policy allowing access to flags based on 'viewKey' role attribute" lines wrap theme={null} [ { "effect": "allow", "actions": ["*"], "resources": [ "proj/${roleAttribute/projectKey}:env/*:flag/*;view:${roleAttribute/viewKey}" ] } ] ``` This statement allows access to all actions on flags in the project specified by `projectKey`, in all environments, provided the flags are linked to the view specified by `viewKey`. If the `viewKey` role attribute is only used in a selector, LaunchDarkly may not prompt you to [set its value](#set-role-attribute-values) when you assign this role to a member or team using the LaunchDarkly UI. If this happens, use the [Modify an account member](/docs/api/account-members/modify-an-account-member) REST API to set the value of the role attribute. Here's an example request body that gives the `viewKey` role attribute a value of `exampleView` for a member: ```json title="Modify an account member to set a role attribute value" lines wrap theme={null} curl -X PATCH https://app.launchdarkly.com/api/v2/members/ \ -H "Authorization: " \ -H "Content-Type: application/json" \ -d '[ { "op": "replace", "path": "/roleAttributes/viewKey", "value": ["exampleView"] } ]' ``` #### Flag creation and multiple views 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. ### Tags and role scope You cannot use role attributes in tag-based policy statements. For most role-scoping use cases, use views instead of tags. Views provide a supported way to group resources and assign access within a project. To learn more, read [Onboarding to views](/docs/guides/account/views-onboarding) and [Use views in complex policy statements](#use-views-in-complex-policy-statements).