LaunchDarkly Integration

LaunchDarkly feature management automation

208 operations availableDeveloper Tools

Launchdarkly is the feature management platform teams use to roll out, target, and test features behind flags. The NoClick Launchdarkly node talks to the Launchdarkly API, so a workflow can create feature flags and environments, copy settings from one flag to another, spin up experiments and new iterations, open and apply approval requests, and add teams and flag followers. It also handles account setup work like creating data export destinations and running big segment imports and exports. Drop it onto the canvas to turn flag and release chores that usually happen by hand into steps that run on a schedule or in response to an event.

What you can automate with LaunchDarkly

Pick one to start building it.

LaunchDarkly Operations

Triggers1

Feature Flags7

Projects8

Environments7

Segments18

Webhooks5

Members2

Account6

Feature flags7

Approvals12

Code references13

Data Export destinations10

Contexts10

Experiments8

Teams7

Account members5

Relay Proxy configurations6

Access tokens5

Other5

Flag triggers5

Integration audit log subscriptions5

Metrics4

OAuth2 Clients5

Holdouts5

Scheduled changes5

Custom roles4

User settings5

Audit log4

Follow flags4

Workflows4

Users4

Announcements4

Layers3

Workflow templates3

Context settings1

Tags1

Templates using LaunchDarkly

LaunchDarkly Flag Change Watchdog

+1

Watches every LaunchDarkly flag change and posts one Slack line saying who changed what, in which environment, and why your policy says it matters, with no ability to change a flag itself. Most flag changes are fine and one of them is the whole incident, and the difference usually sits in an audit log nobody reads. This agent watches account activity, ignores everything that is not a flag change, and posts three lines to Slack: who changed what, before and after, and why your policy says it matters, plus a risk line when the policy is explicit about it. It cannot flip anything back, which is the design, because the person who owns the rollout should be the one making that call. ## What people use it for - **Production changes get a witness** - A rollout going from a quarter of traffic to everyone is announced in the channel as it happens, with the changer, the environment and the numbers, so a release is visible to people who were not in that browser tab. - **Kill switches treated as such** - Turning targeting off on a fraud hold or a rate limiter looks tiny in an audit log and enormous an hour later. Naming those flags in your policy earns them an explicit risk line and a person to confirm it. - **Flags untouched for a year** - The flag's own status comes back with the change, so a permanent flag last modified fourteen months ago is called out as exactly that instead of reading like routine housekeeping. - **Staging noise stays in staging** - The environment key is read off the audit entry rather than assumed, so a dozen experiments a day on a shared staging box never reach a channel that exists to watch production. ## Before you fork **Can it roll a flag back if someone breaks production?** No, and it is built that way on purpose. It reads flags, flag status and the audit log, and it writes only to Slack. A rollback is a production change with its own approval path, and an agent reading one audit entry does not have the context to make it. What it gives you instead is the change and the named owner within seconds of it happening. **Our team changes flags all day. Will this be constant noise?** It reacts to flag changes only, and how loud those get is set by the policy you write, so protected environments and named kill switches produce a message while routine work in lower environments does not. Everything it drops is dropped silently. If the channel is still busier than you want, tighten the policy rather than the trigger. **What LaunchDarkly access does it need?** A reader level API token that can read flags, flag status and the audit log, plus the Slack channel for the notes. No writer or admin role is required, and granting one would add risk without adding a capability. Your flag policy is filled in during fork, and can be edited any time after.

5904 nodes

Frequently asked questions

Use LaunchDarkly as an AI agent tool

Wire LaunchDarkly into a coding agent and let it use these operations as tools.

claude-code
Claude Code
OpenAI
Codex
opencode
OpenCode
openclaw
OpenClaw
hermes
Hermes

Ready to build with LaunchDarkly?

Start building workflows in minutes with our visual builder. No code required.

Book Demo
Browse all integrations