Change requests

A change request stages a proposed flag change so other people can review it before it applies. Modeled on a pull request: someone proposes the change, reviewers approve or reject, the change applies once it has enough approvals.

When to use them

• A production environment where every flag change needs sign-off.
• A regulated environment where you need a record of who approved what.
• A team where some members can propose changes but should not apply them unilaterally.

For a development environment, leave change requests off and let edits land directly.

Turning them on

Two places control change requests:

1. Organization features: an admin turns on “approvals configuration” for the organization. Without this, the rest of the feature is hidden.
2. Environment settings: per environment, turn on approval required and set:
   • How many approvals are needed (1 to 5).
   • Whether the requester can also count as an approver.

When approval is required on an environment, every flag-config change in that environment becomes a change request instead of applying directly.

See Organization features for the org-level toggle.

The flow

1. Propose. You edit the flag in the dashboard exactly as you would without approvals. On Save, instead of applying, the system creates a pending change request with your proposed payload.
2. Review. Other members open the change request, see the diff against the current state, and approve or reject. Each reviewer can leave a comment.
3. Apply. Once the request has enough approvals and no rejections, anyone with permission can click Apply. The system applies the change and writes an audit entry showing both the applier and every approver.

A change request can be withdrawn by its requester at any time before it applies.

Expiry

A change request can be configured to expire if it does not collect enough approvals by a deadline. Expired requests cannot be applied. This keeps the queue clean.

What does not go through change requests

Only changes to the flag’s environment config go through approvals. Changes that do not touch live behavior bypass:

• Renaming or describing a flag.
• Changing the maintainer.
• Creating a new flag.
• Archiving or deleting a flag.

These apply directly and write to the audit log. Approval gates the dial that affects users, not the labels on the dial.

Permissions

Anyone with write permission on the flag (or the environment) can submit a change request. Anyone with the approve-change-request permission can approve, regardless of whether they were specifically invited as a reviewer.

See Members and roles for the permission shape.

Related

• Audit log for the record the apply step leaves behind.
• Workflows when the change should also schedule or progressively roll out.
• Environments for the per-environment toggle.