# Coordinating releases

Coordinate releases across applications and teams using LaunchDarkly feature flags. These strategies enable autonomous teams to manage dependent releases with minimal overhead.

## Overview

When multiple applications or teams need to coordinate releases, LaunchDarkly provides several strategies to manage dependencies without requiring synchronous communication or manual coordination.

Each coordination strategy describes:

- **What people need to do**: How teams work in LaunchDarkly (create flags, configure approvals, grant permissions)
- **What technical setup is required**: How developers implement the coordination (evaluate flags, pass metadata, handle dependencies)

## Coordination strategies

### Prerequisite flags

Use prerequisite flags when applications share a LaunchDarkly project and need to coordinate releases.

**Best for:**

- Tightly coupled applications and services
- Teams that share a project
- Large initiatives with multiple dependent releases
- Frontend and backend components that must be released together

To learn more, read *[Prerequisite flags](./prerequisite-flags.md)*.

### Request metadata

Use request metadata when services communicate via APIs and need to manage breaking changes or versioning.

**Best for:**

- API services with external consumers
- Microservices communicating via HTTP or RPC
- Applications that need to maintain backward compatibility
- Services in separate projects

To learn more, read *[Request metadata](./request-metadata.md)*.

### Delegated authority

Use delegated authority when cross-functional teams need to manage flags across multiple projects.

**Best for:**

- Cross-functional collaboration with customer success, support, or sales teams
- Database administrators managing schema migrations
- Security engineers managing security features
- Teams that need to control flags in projects they do not own

To learn more, read *[Delegated authority](./delegated-authority.md)*.

## Choosing a strategy

Use this guide to select the appropriate coordination strategy:

| Scenario | Strategy | Why |
|----------|----------|-----|
| Frontend and backend for the same product | Prerequisite flags | Same project, tightly coupled |
| API with third-party consumers | Request metadata | Different projects, version management |
| Multiple microservices, same product | Prerequisite flags or Request metadata | Depends on coupling and API design |
| Customer success managing early access | Delegated authority | Cross-functional collaboration |
| Database team managing migrations | Delegated authority | Cross-project coordination |

## Combining strategies

Strategies can be combined for complex scenarios:

**Delegated authority with prerequisites:**

Grant customer success teams permission to manage prerequisite flags that control early access programs across multiple applications.

**Request metadata with delegated authority:**

Allow API consumers to request custom targeting rules for their specific API versions or client configurations.

## Project architecture considerations

Coordination strategy selection affects project architecture decisions:

- Applications using **prerequisite flags** should share a project
- Applications using **request metadata** or **delegated authority** can be in separate projects
- Applications in the same project have access to all coordination strategies

To learn more about project architecture, read *[Projects and environments](../../platform-readiness/projects-and-environments/index.md)*.

<div class="page-metadata"><table class="page-metadata-table" aria-label="Page metadata"><thead><tr><th scope="col">Last modified</th><th scope="col">Last reviewed</th><th scope="col">Review due</th></tr></thead><tbody><tr><td><time datetime="2026-03-19">2026-03-19</time></td><td></td><td></td></tr><tr><td>Last commit: <a href="https://github.com/launchdarkly-labs/ps-flag-book/commit/d319a7d">d319a7d</a></td><td></td><td></td></tr></tbody></table></div>