This topic is a complete reference of all actions that are available to use in role policies. It includes tables with all supported actions and details about them. Each action is scoped to a resource type.
Actions represent changes you can make to resources, such as createFlag, deleteFlag, updateName, and more.
To learn more about how actions work within role policies, read Member role concepts.
When new features are added to LaunchDarkly, there may be new associated actions. We recommend reviewing these actions periodically to determine if you want to add them to any of your roles. If you are using preset roles provided by LaunchDarkly, you can choose when to update your preset roles to the latest versions. To learn how, read Update organization roles and Update project roles.
This table describes new actions that have been added to LaunchDarkly in the last year:
These are all the actions you can take, sorted by resource type.
When you create a policy using the policy builder, actions relevant to the resource scope you’ve selected automatically appear in the policy builder:
When you create a policy using the advanced editor, you can specify actions individually, or in bulk using glob syntax and wildcards. For example, you can describe all modifications to feature flags with the action specifier update*.
acct is a top-level resource. A code sample is below:
This table explains the available account actions:
This table explains the available account ownership actions:
agent-graph is a child resource of a project. A code sample is below:
This table explains the available Agent graphs actions:
The product AgentControl and AgentControl configs were previously called “AI Configs” in the UI and documentation. Custom roles still use the existing aiconfig and similarly named actions.
aiconfig is a child of both a project and an environment. The code example below grants permission to update targeting rules for all AgentControl configs across all projects and environments.
This table explains the available AgentControl actions related to settings and targeting changes:
This table explains AgentControl actions related to collaboration:
ai-tool is a child resource of a project. A code sample is below:
This table explains the available AI tool actions:
ai-model-config is a child resource of both a project and an environment. A code sample is below:
This table explains the available AI model config actions:
ai-dataset is a child resource of a project. A code sample is below:
This table explains the available AI dataset actions:
ai-evaluation is a child resource of a project. A code sample is below:
This table explains the available AI evaluation actions:
alert is a child of a project. Alerts are related to the observability feature.
A code sample is below:
To learn more, read Alerts.
application is a top-level resource. A code sample is below:
This table explains the available application actions:
version is a child resource of applications. A code sample is below:
This table explains the available application version actions:
code-reference-repository is a top-level resource. A code sample is below:
To learn more, read Code references.
This table explains the available code reference actions:
context-kind is a child of a project. A code sample is below:
To learn more, read Context kinds.
This table explains the available context kind actions:
destination is a child of both a project and an environment. A code sample is below:
To learn more, read Data Export.
This table explains the available Data Export destination actions:
domain-verification is a top-level resource. A code sample is below:
To learn more, read Domain verification.
This table explains the available domain verification actions:
env is a child of a project. A code sample is below:
To learn more, read Environments.
This table explains the available environment actions:
error is a child of a project. Errors are related to the observability feature.
A code sample is below:
To learn more, read Error monitoring.
experiment is a child of both a project and an environment. A code sample is below:
To learn more, read Experimentation.
This table explains the available experiment actions:
flag is a child of both a project and an environment. A code sample is below:
To learn more, read Creating new flags.
Some feature flag actions affect only the current environment. Other feature flag actions affect all environments in a project.
This table explains feature flag actions related to targeting changes. Unless otherwise specified, these actions affect only the current environment:
This table explains feature flag actions related to flag settings. Each of these actions affects all environments in a project:
This table explains feature flag actions related to environment-specific settings:
This table explains feature flag actions related to collaboration:
This table explains feature flag actions related to other flag changes:
holdout is a child of both a project and an environment. A code sample is below:
To learn more, read Holdouts.
This table explains the available holdout actions:
Most third-party integrations use a shared set of custom role actions.
integration is a top-level resource. A code sample is below:
To learn more, read Integrations.
This table explains the available integration actions:
layer is a child of a project. A code sample is below:
To learn more, read Mutually exclusive experiments.
This table explains the available layer actions:
log is a child of a project. Logs are related to the observability feature.
A code sample is below:
To learn more, read Logs.
member is a top-level resource. A code sample is below:
To learn more, read Members.
This table explains the available member actions:
metric is a child of a project. A code sample is below:
To learn more, read Metrics.
This table explains the available metric actions:
metric-data-source is a child of both a project and an environment. A code sample is below:
To learn more, read Metric data sources.
This table explains available metric data source actions:
metric-group is a child of a project.
A code sample is below:
To learn more, read Metric groups.
This table explains the available metric group actions:
Guardrail metric groups are no longer available. Configure release guardrails by adding individual metrics and metric groups to release policies.
This table explains the available guardrail metrics group actions:
notification-subscription is a child of both a project and an environment. A code sample is below:
To learn more, read Update your notification settings.
This table explains the available notification subscription actions:
observability-settings is a child of a project. A code sample is below:
To learn more, read Observability.
observability-dashboard is a child of a project. A code sample is below:
To learn more, read Dashboards.
pending-request is a top-level resource. A code sample is below:
To learn more, read Accept pending requests.
This table explains the available pending request actions:
token is a child of a member. A code sample is below:
To learn more, read API access tokens.
This table explains the available personal access token actions:
proj is a top-level resource. A code sample is below:
To learn more, read Projects.
This table explains the available project actions:
Starting in October 2024, all new roles start with no access. This means the roles cannot take any actions on any resources. Make sure to add explicit permission to view projects to any roles that you create.
Older custom roles may have read-only access to all resources by default. This is because roles created prior to October 2024 had the option to use the Reader base role as their starting point, rather than starting with no access.
To learn more, read Project roles and Create private projects with custom roles.
relay-proxy-config is a top-level resource for which you can allow or deny certain actions.
Here is an example:
To learn more, read Automatic configuration.
This table explains the available Relay Proxy automatic configuration actions:
release-pipeline is a child of a project. A code sample is below:
This table explains the available release pipeline actions:
release-policy is a child of a project.
To learn more, read Release policies.
This table explains the available release policy actions:
role is a top-level resource. A code sample is below:
To learn more, read Roles.
This table explains the available role actions:
sdk-key is a child of both a project and an environment. A code sample is below:
To learn more, read SDK credentials.
This table explains the available SDK key actions:
segment is a child of both a project and an environment. A code sample is below:
To learn more, read Segments.
This table explains the available segments actions:
service-token is a top-level resource. A code sample is below:
To learn more, read API access tokens.
This table explains the available service access token actions:
session is a child of a project. Sessions are related to the observability feature.
A code sample is below:
To learn more, read Session replay.
team is a top-level resource. A code sample is below:
To learn more, read Teams.
This table explains the available team actions:
The deny effect for your resource in the viewTeam action hides the teams you specify from the member. The allow effect for the same resource and action pairing doesn’t do anything because your account member can already view the team.
To learn more, read Create private teams.
template is a top-level resource. A code sample is below:
To learn more, read Workflow templates.
This table explains the available workflow template actions:
trace is a child of a project. Traces are related to the observability feature.
A code sample is below:
To learn more, read Traces.
vega is a child of a project. Vega is the observability feature AI agent.
A code sample is below:
To learn more, read Vega.
view is a child of a project. A code sample is below:
To learn more, review Views.
This table explains the available view actions:
webhook is a top-level resource. A code sample is below:
To learn more, read Webhooks.
This table explains the available webhooks actions: