How do we configure approval workflows and scheduled releases in LaunchDarkly?

Fast releases are only useful if you can trust them in production. Approvals and scheduled releases in LaunchDarkly give you that trust: you can gate risky changes behind review, automate rollouts for when the right people are online, and recover instantly—no redeploys required.

Quick Answer: You configure approval workflows in LaunchDarkly by defining where approvals are required (environments, flags, tags) and who can grant them, then wiring them into workflows or external tools like ServiceNow. You schedule releases by using workflows to time‑box changes to flag targeting rules, so rollouts and rollbacks happen automatically in production.

The Quick Overview

What It Is: A set of runtime controls in LaunchDarkly—approvals, workflows, and scheduling—that let you control when a change goes live and who must sign off before it does.
Who It Is For: Engineering, SRE, and product teams that need faster releases without 2am fire drills, especially in regulated or high‑risk environments.
Core Problem Solved: Coordinating safe, auditable releases across teams and time zones without waiting on deploys or manually flipping flags in the UI.

How It Works

LaunchDarkly evaluates feature flags at runtime via 25+ SDKs and pushes changes globally in under 200ms. Approvals and workflows sit on top of that runtime control plane:

Approvals decide who has to sign off on a change before it can affect production.
Workflows and scheduling decide when a change should apply and how it should progress (for example, 1% → 25% → 100% rollout).
Automated triggers (metrics, alerts, external change requests) decide if a change should continue, pause, or rollback.

Because everything happens after deploy, you can adjust targeting, roll back, or promote a feature in real time, backed by audit logs and policies.

1. Define your approval policy

This is where you decide:

Which environments require approvals
- Typical pattern: approvals in production (and sometimes staging), but not in dev.
- For example: require approvals in production for customer‑facing flags that could impact revenue or reliability.
Which resources are in scope
- Require approvals for:
  - All flags in an environment, or
  - Only flags and segments with specific tags (for example, critical, payments, ai-config, beta).
- This lets you keep low‑risk experiments fast while tightly controlling high‑blast‑radius changes.
Which approval system to use
- LaunchDarkly approvals: Use the built‑in experience to request, review, and approve changes directly in LaunchDarkly.
- ServiceNow approvals: Use ServiceNow as the system of record, then:
  - Link LaunchDarkly changes to ServiceNow change requests.
  - Optionally auto‑apply changes when the external change request is approved, so your runtime config stays in sync with your change management process.

2. Configure the approval workflow

Once the policy is set, you configure how approvals actually work day to day:

Who can request changes
- Typically product managers, engineers, or release managers.
- They propose edits to a flag’s targeting (for example, “roll out feature X to 10% of US traffic”).
Who can approve
- Use LaunchDarkly’s custom roles and policies to define approvers:
  - For example: “SRE or engineering manager must approve changes to production flags tagged critical.”
- This gives you separation of duties and clearer guardrails.
What happens on approval
- When an approval is granted:
  - LaunchDarkly applies the change instantly across your environments in under 200ms, or
  - If you’re connected to an external tool like ServiceNow, approvals there can automatically trigger the change in LaunchDarkly.
What happens on rejection or timeout
- Rejected changes don’t apply and remain in the audit trail.
- You can require the requester to update, re‑submit, or abandon the proposal.

3. Build scheduled releases with workflows

Approvals keep you safe; scheduled workflows give you speed without babysitting the UI.

With LaunchDarkly workflows, you can:

Pre‑define a rollout plan.
Set exact dates/times for each step.
Attach approvals at specific steps.
Automate rollbacks based on metrics from external tools.

A typical scheduled release might look like:

Phase 1 – Schedule the initial rollout
- Create a workflow for a specific flag in production.
- Step 1 (for example, Monday 09:00 UTC):
  - Target internal users or a small percentage of traffic (for example, 1% of beta_users).
  - Require approval from an engineering lead or SRE before this step executes.
- Schedule this step to run automatically once approvals are in place.
Phase 2 – Progressive rollout with guardrails
- Step 2 (for example, Monday 13:00 UTC):
  - Increase exposure to 25–50% of your target segment.
  - Optional: require a second approval (for example, product + SRE) before proceeding.
- Use external monitoring and observability tools:
  - Configure automated changes based on metrics (for example, error rate, latency, conversion).
  - If a metric crosses a threshold, a workflow can update the flag’s targeting rules—pause, reduce exposure, or roll back.
Phase 3 – Full rollout or rollback
- Step 3 (for example, Tuesday 09:00 UTC):
  - Move to 100% rollout if metrics are healthy.
  - Or automatically revert to a safe configuration if your monitoring tools signal a problem.
- Because LaunchDarkly is a runtime control plane, all of these transitions happen without a new deploy.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Approvals	Requires review before changes to flags/segments take effect in an environment.	Reduces blast radius and enforces governance for critical changes.
Scheduled workflows	Automates future changes to flag targeting rules at specific times.	Enables predictable, no‑drama releases without manual toggling.
Metric‑driven automation	Uses external metrics to trigger flag changes (progress, pause, rollback).	Cuts incident response time and enables automated rollback.

Ideal Use Cases

Best for production releases with high risk: Because you can mandate approvals, constrain changes to tagged critical flags, and run a guarded rollout that can auto‑rollback based on metrics.
Best for coordinated cross‑team launches: Because workflows let product, marketing, and engineering align on a single schedule—features go live at 9am local time, not whenever someone remembers to flip a flag.

Limitations & Considerations

Approvals can slow trivial changes: If you require approvals for every change in every environment, you’ll add friction. Use tags and environment‑specific policies so teams can move fast where risk is low.
Automation is only as good as your signals: Metric‑driven rollouts and rollbacks depend on clean data. Make sure your observability tools and thresholds are well‑configured before fully automating high‑impact releases.

Pricing & Plans

Approval workflows and scheduled releases live in LaunchDarkly’s broader runtime control platform. Exact access can vary by plan and contract, but the general pattern is:

Team or Growth‑oriented plans: Best for product and engineering teams that want to start using feature flags and basic workflows to decouple deploy from release.
Enterprise plans: Best for organizations that need advanced governance—approvals across multiple environments, ServiceNow integration, custom roles, audit logs, and automated, metric‑driven workflows at scale.

For the latest details on which capabilities are available in each plan, check LaunchDarkly’s pricing page or talk to sales.

Frequently Asked Questions

How do we decide which environments should require approvals?

Short Answer: Require approvals where the blast radius is largest—typically production—and keep lower environments fast and flexible.

Details:
Approvals shine when a mistake would wake up the on‑call or impact customers. A common configuration is:

Production: Approvals required for all flags tagged critical, payments, or ai-config.
Staging/UAT: Approvals for a narrower set of flags, or none if the environment is low risk.
Dev/Test: No approvals, so engineers can iterate quickly.

This setup balances speed and safety: teams ship fast in dev, while production changes get a short, structured review cycle.

Can we trigger LaunchDarkly changes automatically when a ServiceNow change is approved?

Short Answer: Yes. You can use ServiceNow as the approval system and automatically apply changes in LaunchDarkly when the associated change request is approved.

Details:
When you connect LaunchDarkly to ServiceNow:

A proposed change to a flag (or segment) in a protected environment creates or links to a ServiceNow change request.
The review and approval process happens in ServiceNow, following your existing ITIL or change‑management policies.
When the request is approved, LaunchDarkly can automatically apply the associated flag changes—no manual step in the LaunchDarkly UI required.
The full history remains visible via LaunchDarkly’s audit logs and in your change‑management system.

This keeps runtime control aligned with your enterprise governance without adding manual glue work for engineers.

Summary

Configuring approval workflows and scheduled releases in LaunchDarkly lets you move at release speed without sacrificing control. You decide where approvals are mandatory, which flags they apply to, and whether LaunchDarkly or ServiceNow is the source of truth. Then you use workflows to schedule and automate rollouts, including metric‑driven pauses and rollbacks. The result: safer production releases, fewer 2am fire drills, and a clear, auditable path from “proposal” to “live” without touching your deployment pipeline.

Next Step

Get Started