Using actions
Overview
This topic explains how to use actions in custom roles policies. It includes tables with all supported actions and details about them. These actions are scoped by 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 custom role policies, read Custom role concepts.
Recently added actions
When new features are added to LaunchDarkly, there may be new associated actions. We recommend reviewing these actions periodically to determine if they should be added to any of your custom roles.
This table describes new actions that have been added to LaunchDarkly recently:
Actions reference
These are all the actions you can take, sorted by each 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*
.
Account actions
Expand Account actions
acct
is a top-level resource. A code sample is below:
This table explains available account actions:
Account ownership actions
This table explains available account ownership actions:
AI Config actions
Expand AI Config actions
aiconfig
is a child resources of projects. A code sample is below:
This table explains available AI Config actions:
AI model config actions
Expand AI model config actions
ai-model-config
is a child resources of projects. A code sample is below:
This table explains available AI model config actions:
Application actions
Expand Application actions
application
is a top-level resource. A code sample is below:
This table explains available application actions:
Application version actions
Expand Application version actions
application version
is a child resource of applications. A code sample is below:
This table explains available application version actions:
Code reference actions
Expand Code reference actions
code-reference-repository
is a top-level resource. A code sample is below:
To learn more, read Code references.
This table explains available code reference actions:
Context kind actions
Expand Context kind actions
context-kind
is a child of a project. A code sample is below:
To learn more, read Context kinds.
This table explains available context kind actions:
Destination actions
Expand Destination actions
destination
is a child of both a project and environments. A code sample is below:
To learn more, read Data Export.
This table explains available Data Export destinations actions:
Domain verification actions
Expand Domain verification actions
domain-verification
is a top-level resource. A code sample is below:
To learn more, read Domain verification.
This table explains available domain verification kind actions:
Environment actions
Expand Environment actions
env
is a child resource of projects. A code sample is below:
To learn more, read Environments.
This table explains available environments actions:
More information about viewSdkKey
The deny
effect in the viewSdkKey
action hides the server-side SDK key you specify from the member. However, the allow
effect for the same resource and action pairing doesn’t do anything. Your LaunchDarkly member does not need explicit permission to view the keys, because all custom roles can view all environments in a LaunchDarkly instance by default.
Experiment actions
Expand Experiment actions
experiment
is a child of both a project and environments. A code sample is below:
To learn more, read Experimentation.
This table explains available experiment actions:
Layer actions
Expand Layer actions
layer
is a child of a project. A code sample is below:
To learn more, read Mutually exclusive experiments.
This table explains available layer actions:
Feature flag actions
Expand Feature flag actions
flag
is a child of both a project and environments. 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 affect 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 actions
Expand Holdout actions
holdout
is a child of both a project and an environment. A code sample is below:
To learn more, read Holdouts.
This table explains available holdout actions:
Integration actions
Expand Integration 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 available integrations actions:
Member actions
Expand Member actions
member
is a top-level resource. A code sample is below:
To learn more, read Account members.
This table explains available member actions:
Metric actions
Expand Metric actions
metric
is a child resource of projects. A code sample is below:
To learn more, read Metrics.
This table explains available metric actions:
Metric group actions
Expand Metric group actions
metric-group
is a child resource of projects. A code sample is below:
To learn more, read Metric groups.
This table explains available metric group actions:
Pending request actions
Expand Pending request actions
pending-request
is a top-level resource. A code sample is below:
To learn more, read Accept pending requests.
This table explains available personal access token actions:
Personal access token actions
Expand Personal access token actions
token
is a child resource of members. A code sample is below:
To learn more, read API access tokens.
This table explains available personal access token actions:
Project actions
Expand Project actions
proj
is a top-level resource. A code sample is below:
To learn more, read Projects.
This table explains available project actions:
More information about viewProject
The deny
effect in the viewProject
action hides the projects you specify from the member. However, the allow
effect for the same resource and action pairing doesn’t do anything. Your LaunchDarkly member does not need explicit permission to view the project, because all custom roles can view all projects in a LaunchDarkly instance by default.
To learn more, read Create private projects with custom roles.
Relay Proxy configuration actions
Expand Relay Proxy configuration actions
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 available Relay Proxy automatic configuration actions:
Release pipeline actions
Expand Release pipeline actions
release-pipeline
is a child of project. A code sample is below:
This table explains available release pipeline actions:
Role actions
Expand Role actions
role
is a top-level resource. A code sample is below:
To learn more, read Custom roles.
This table explains available role actions:
Segment actions
Expand Segment actions
segment
is a child of both a project and environments. A code sample is below:
To learn more, read Segments.
This table explains available segments actions:
Service access token actions
Expand Service access token actions
service-token
is a top-level resource. A code sample is below:
To learn more, read API access tokens.
This table explains available service access token actions:
Team actions
Expand Team actions
team
is a top-level resource. A code sample is below:
To learn more, read Teams.
This table explains available team actions:
More information about the viewTeam action
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 actions
Expand Template actions
template
is a top-level resource. A code sample is below:
To learn more, read Workflow templates.
This table explains available workflow template actions:
Webhook actions
Expand Webhook actions
webhook
is a top-level resource. A code sample is below:
To learn more, read Webhooks.
This table explains available webhooks actions: