For AI agents: a documentation index is available at the root level at /llms.txt and /llms-full.txt. Append /llms.txt to any URL for a page-level index, or .md for the markdown version of any page.
Sign inTry it free
DocsGuidesSDKsIntegrationsAPI docsTutorialsFlagship blog
DocsGuidesSDKsIntegrationsAPI docsTutorialsFlagship blog
  • Get started
    • Overview
    • Onboarding
    • Get started
    • Launch Insights
    • LaunchDarkly architecture
    • LaunchDarkly vocabulary
  • AgentControl
    • AgentControl
    • Manage AgentControl
  • Feature flags
    • Create flags
    • Target with flags
    • Flag templates
    • Manage flags
    • Code references
    • Contexts
    • Segments
  • Releases
    • Releasing features with LaunchDarkly
    • Release policies
    • Percentage rollouts
    • Progressive rollouts
    • Guarded rollouts
    • Feature monitoring
    • Release pipelines
    • Engineering insights
    • Release management tools
    • Applications and app versions
    • Change history
    • Restoring previous flag versions
  • Observability
    • Observability
    • Session replay
    • Error monitoring
    • Logs
    • Traces
    • Observability metrics
    • Product analytics events
    • LLM observability
    • Alerts
    • Dashboards
    • Service map
    • Vega for auto-remediation
    • Observability MCP server
    • Search specification
    • Observability settings
    • Observability integrations
  • Experimentation
    • Experimentation
    • Experiment metric types
    • Experiment configuration
    • Managing experiments
    • Analyzing experiments
    • Multi-armed bandits
    • Holdouts
  • Metrics and events
    • Metrics in LaunchDarkly
    • Creating metrics
    • Metric groups
    • Events
    • Autogenerated metrics
  • Warehouse native
    • Warehouse native metrics
    • Setting up external warehouses
    • Creating experiments using warehouse native metrics
  • Infrastructure
    • Connect apps and services to LaunchDarkly
    • LaunchDarkly in China and Pakistan
    • LaunchDarkly in the European Union (EU)
    • LaunchDarkly in federal environments
    • Public IP list
  • Your account
    • Projects
    • Views
    • Environments
    • Tags
    • Teams
    • Members
    • Roles
      • Member role concepts
        • Using actions
        • Using resources
        • Using role scope
        • Using policies
        • Using the advanced editor
      • Managing role assignments
      • Managing roles
    • Account security
    • Feature previews
    • Billing and usage
    • Changelog
Sign inTry it free
LogoLogo
On this page
  • Overview
  • About the policy algorithm
  • About policies
  • Create policies in the policy builder
  • Create policies in the advanced editor
Your accountRolesMember role concepts

Using policies

Was this page helpful?
Previous

Using the advanced editor

Next
Built with

Overview

This topic explains how to work with policies for roles, integrations access, and Relay Proxy access.

Policies combine resources and actions into a set of statements that define what members can or cannot do in LaunchDarkly. To learn more, read Member role concepts.

To create a new role, read Creating roles and policies.

About the policy algorithm

The algorithm for determining whether a policy allows or denies access is as follows:

  • If a statement within a policy explicitly denies access to a resource and action, access is denied. This statement overrides any other statement in the policy that allows access to the resource and action.
  • If a statement within a policy explicitly allows access to a resource and action, and no statement denies access, access is allowed.
  • If two different policies have conflicting permission levels, the more permissive level of access is applied.
  • Any resource or action not specifically included within a policy is denied by default.

Statement order does not matter.

Roles and access tokens

Account members can create access tokens that are limited to their existing permissions.

To learn more, read Minimum required actions.

You can assign multiple roles to one member, and each role has its own set of policy statements.

Permissions are cumulative across roles. If you assign multiple roles to a member, and one of those roles allows access to a resource, then access is allowed even if other roles deny that access. Adding roles to a member can only increase that member’s access.

About policies

Policies combine resources and actions into a set of statements that define what members can or cannot do in LaunchDarkly.

You use LaunchDarkly’s Policy builder to build roles by selecting combinations of resources and actions the role is allowed to or forbidden from taking on them.

You can define the resources explicitly in the role, or you can define them based on a parameter that you create. This parameter is called a role attribute. For example, you can 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.

You can create most roles using the graphical Policy builder. If needed, you can also define a role directly in JSON, using the advanced editor.

Create policies in the policy builder

When you create a policy using the policy builder, you use the Scope menu to specify the resources this policy affects, and the Actions menu to specify whether to allow or deny particular actions on these resources:

The "Scope" and "Actions" menus in a policy.

The "Scope" and "Actions" menus in a policy.

To learn more, read Create policies for roles.

Create policies in the advanced editor

The advanced editor uses JSON to specify the policy.

For a full list of available resources, read Using resources. Resource specifiers can also include modifiers, such as tags and property-based selectors. To learn more, read Member role concepts.

You can create detailed and complex policies with the advanced editor. To learn more, read Using the advanced editor.