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 them rather than with 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

When an account member has one or more roles, then the account member’s access is defined by the roles. If the roles have conflicting permissions levels, the more permissive level of access is applied. For example, if a member has one role that allows access to a resource, and another role that restricts access to a resource, the member is allowed access.

If a team has one or more roles, then for each account member on the team, the account member’s access is defined by both the member’s role and the roles assigned to the team. For example, if a member has the preset LaunchDarkly Architect role, the LaunchDarkly Architect access is used in addition to the access defined by the roles assigned to the team.