Skip to main content

Approvals and pending changes

Approvals protect sensitive flag, guarded-release, experiment, segment, and configuration changes. Open Project → Approvals to see requests grouped into Pending, Approved, and Applied columns.

Configure approval policy​

Open Project settings → Approval settings. For each environment, define whether approval is required, minimum approvals, whether requestors may self-review, whether any rejection blocks apply, tag scope, and whether scheduled changes can be deleted without approval. Production commonly requires more reviewers than Test.

Request and review a change​

Select Request change, provide a title, description, environment, resource, and JSON Patch operations. A patch is an ordered list such as:

[
  {"op":"replace","path":"/on","value":true},
  {"op":"replace","path":"/fallthrough/rollout/variations/0/weight","value":10000}
]

Reviewers select Approve or Reject and may leave a comment. FlagTGL records reviewer, decision, timestamp, and comment. Once the required approval count is reached, the request becomes approved. Select Apply change to execute it immediately, or set scheduled_at to keep it pending until the requested time. Rejected requests remain visible for audit.

Self-review is enforced by policy. A request cannot be applied while approvals are incomplete, while a blocking rejection exists, or before its scheduled time. Application records applied_at and the resulting resource audit event.

API​

GET  /api/orgs/{org}/projects/{projectID}/change-requests
POST /api/orgs/{org}/projects/{projectID}/change-requests
POST /api/orgs/{org}/projects/{projectID}/change-requests/{id}/reviews
POST /api/orgs/{org}/projects/{projectID}/change-requests/{id}/apply

LaunchDarkly approval requests and pending instructions are imported with their operations, reviewers, approval requirement, schedule, and source identifiers. Provider-only fields remain in the raw payload.