# Review pending LaunchDarkly flag changes in one inbox

> Every flag change waiting on review in one queue, grouped by environment, with approve, deny, and a one click risk check before you decide.

- Workflow type: app
- Services: LaunchDarkly, Slack Bot
- Categories: Engineering, Operations
- Published: 2026-08-24

## What it does

- Pulls every flag change waiting on review into a single queue, grouped by environment with production at the top, so approvals stop living in scattered Slack threads.
- Shows who asked for the change, which environment it touches, how long it has been waiting, and what the change actually does in plain language, right next to the flag's current state so you can see before and after.
- Lets reviewers approve or deny with a comment in place, then push an approved change live without leaving the page. Every decision posts to your team channel automatically.
- Adds a Risk check button that sends an agent to work out the blast radius, find anything depending on the flag, and write a short risk note onto the request before you decide.

## What you'll need

- A LaunchDarkly account on a plan that includes approvals. Approvals are a paid tier feature, so teams on the free plan will not have a queue to review.
- A LaunchDarkly access token with permission to review and apply changes, not just read them.
- A Slack workspace and a channel where approval decisions should be announced.
- Optional: connected code repositories in LaunchDarkly, which lets the risk check report how widely a flag is used in your codebase.

## Prompt

Build me an app that acts as a review inbox for pending LaunchDarkly feature flag change approvals, so change reviews stop living in Slack threads and my reviewers have one screen that shows what is waiting, what it changes, and what it might break.

The main view is a queue of pending approvals. Build it from LaunchDarkly's List approval requests, filtered to requests still awaiting review. Group the queue by environment and always sort the production group to the top, since those are the ones that matter most. Within each group, sort oldest first. For every request show the requester, the project and environment, the flag it targets, and how long the request has been waiting. Highlight anything older than 24 hours with a clear visual treatment and a label explaining why it stands out, because those are the requests holding up a release.

Do not show reviewers a raw diff. Each request carries the instructions describing the change it would make, so translate those into plain language on the card: something like "Turn this flag on in production" or "Increase the rollout from 10 percent to 50 percent of traffic" or "Add the beta-users segment to the targeting rules". Next to that plain language description, show the flag's current state so the reviewer gets a real before and after. Use Get feature flag for the flag's per-environment configuration, and Get flag status across environments so a reviewer can see whether this flag is already live elsewhere. Present it as two columns, current state on the left and what it would become on the right.

Reviewers decide inline. Each request needs an Approve button and a Deny button, both of which take a comment, wired to Review approval request. Approving records the sign-off but does not ship the change. Shipping is a separate Apply button, enabled once a request is approved, wired to Apply approval request. Keep these as two distinct steps so a change can be approved ahead of time and pushed live when the team is ready. LaunchDarkly returns a conflict error if the flag was modified by someone else in the meantime, so if an apply fails that way, re-read the request and the flag, tell the reviewer what changed underneath them, and let them retry rather than silently failing.

Every decision posts to our team channel with Slack's Send a Message. Post as the bot and write the deciding reviewer's name into the message text, along with the flag, the environment, the plain language summary of the change, the decision, and the comment they left. App handlers run under the app owner's connection, so naming the reviewer in the body is what keeps attribution honest rather than making every decision look like it came from one person.

Decided requests move to a "Recently decided" tab rather than vanishing. That tab shows the same request detail plus who decided, what they decided, their comment, and when. Reviewers should be able to look back at recent history without leaving the app.

Add a "Risk check" button on every pending request that fires a background agent. The agent reads the pending change and works out the blast radius: which environment it touches, what share of traffic it affects, and which segments are involved. It calls List dependent feature flags to catch any flag using this one as a prerequisite, since those are the changes that break things unexpectedly. It pulls the flag's recent change history with List audit log entries to see whether this flag has been churning or recently rolled back. It calls Get code references statistics for flags to gauge the code footprint, so a flag referenced in fifty places reads as riskier than one referenced twice. It then writes a short risk note, a few sentences plus a plain low, medium, or high call, which gets stored against that approval request in the app and displayed on the card for the reviewer to read before deciding. Show a pending state on the button while the agent works and surface the note as soon as it lands.

Two things to handle gracefully. Approvals are a paid tier feature in LaunchDarkly, so say that plainly on the page rather than showing a mysteriously empty queue: if the account's plan does not include approvals, explain that the inbox needs a plan with change approvals enabled. Dependent flags and code reference statistics are also gated and depend on connected repositories, so when the risk check cannot get them, have it say which signals were unavailable and give its assessment from the rest instead of erroring out.

Let me set the LaunchDarkly project and the Slack channel for decision notices in one settings area, and let me adjust the 24 hour urgency threshold there too.

## How to customize

- Change the age threshold for the urgency highlight. It flags anything older than 24 hours by default, since those are usually the requests holding up a release.
- Pick which Slack channel decisions post to, adjust the wording of the notice, or turn the announcements off entirely.
- Reorder the environment groups if production is not the one you want at the top, or hide environments your team does not review.

## FAQ

### Do I need a paid LaunchDarkly plan for this?

Yes. Change approvals are only available on LaunchDarkly's paid tiers, so this inbox needs a plan that includes them. If your plan does not, the app says so plainly on the page instead of showing an empty or broken queue.

### Can reviewers see what a change actually does before approving it?

That is the main point of it. Each request is written out in plain language from the requested instructions, and the flag's current state across your environments is shown beside it, so you get a clear before and after rather than a raw diff.

### What does the Risk check button do?

It kicks off a background agent that reads the pending change and works out the blast radius: which environment it hits, what share of traffic is affected, and which audience segments are involved. It also checks whether other flags depend on this one, looks at the flag's recent change history, and sees how widely it appears in your code. It writes a short risk note onto the request for you to read before deciding.

### Does approving a change also make it live?

No, and that is deliberate. Approving records your sign-off, and pushing the change live is a separate click. That way a change can be approved ahead of time and shipped when the team is ready for it.

### What happens to requests after someone decides on them?

They move to a Recently decided tab rather than disappearing, so you can look back at who approved what and when. Every decision is also announced in your team channel as it happens.

Use this prompt in General Input: https://www.generalinput.com/prompts/review-pending-launchdarkly-flag-changes-in-one-inbox