Managing roles assignments

Overview

This topic explains the different role types, and how different roles interact. You can use LaunchDarkly’s roles to give each member precise permissions and access to different aspects of LaunchDarkly.

The other topics in this category explain how to set up and manage roles for the people who use your LaunchDarkly account:

• Assigning roles to members
• Viewing members’ roles
• Changing members’ roles
• Removing members’ roles
• Assigning roles to teams
• Changing account owners

Account members are people who work at your organization or have access rights to your organization’s LaunchDarkly account for another reason, such as contractors or part-time employees. To learn more, read Members.

LaunchDarkly roles

All roles available in LaunchDarkly describe the access that a member or team has within LaunchDarkly. Each role consists of one or more statements that describe the resources the role has access to and the actions the role can take on that resource.

Every LaunchDarkly account comes with several built-in base roles, including Reader, Writer, Admin, and Owner.

Customers on select plans additionally have:

• access to a No access base role.
• access to several organization roles and project roles provided by LaunchDarkly. These provide different sets of permissions that are commonly grouped together, designed around typical personas. For example, LaunchDarkly provides a Developer project role that can perform all flag actions within projects it is assigned to, and a Contributor project role that can make changes to flag status but cannot perform destructive actions on it.
• the ability to create their own roles, sometimes called custom roles. When you create your own role, you define the access using a set of statements called a policy.

Every member must have at least one role assigned to them, either directly or through a team. This is true even if the role explicitly prohibits them from accessing any information within LaunchDarkly.

If you have access to the preset organization and project roles, we encourage you to work with them instead of the base roles for the following reasons:

• they are more likely to map to your organization’s access requirements
• they can be customized using role scope when you assign them to members or teams
• you can edit them if needed, by adding additional policy statements

How roles interact

Base roles, custom roles, and team roles interact with each other differently:

• Base roles and directly-assigned custom roles are mutually exclusive. When you directly assign a member a custom role, that custom role is used instead of the member’s base role to determine the member’s access.
• Custom roles are additive to each other. When you directly assign a member multiple custom roles, those roles will combine to grant the most permissive access.
• Team-assigned custom roles are additive to other kinds of roles. When you add a member to a team with a team-assigned role, any other roles and the team role will combine to grant the most permissive access.

The sections below include examples of each of these scenarios.

How custom roles interact with base roles

If an account member has a both a base role and a custom role assigned, then the custom role takes precedence over the base role.

For example, imagine a member has a base role of “reader” that allows them to view all projects. If you assign that member a custom role that prevents them from viewing Project A, then the custom role takes precedence and they will no longer be able to view Project A.

How custom roles interact with other custom roles

If an account member has two or more custom roles directly assigned to them, and the roles have conflicting permissions levels, then LaunchDarkly applies the more permissive level of access.

For example, imagine a member has a custom role that allows them to view and edit Project A only. If you assign a second custom role that allows viewing and editing Project B, then the role is additive and the member will be able to view and edit both Project A and Project B.

How team roles interact with base roles and custom roles

If an account member has a base or custom role and a team-assigned role, and the roles have conflicting permissions levels, then LaunchDarkly applies the more permissive level of access.

For example, imagine a member has a base role of “reader” that allows them to view, but not edit, all projects. If you add that member to a team with a role that allows editing Project A, then the role is additive and the member will be able to both view and edit Project A.