Why one person shouldn't be able to do this alone
Flags make changing production fast — that's the whole point. But fast cuts both ways: a fat-fingered rollout percentage, a targeting rule aimed at the wrong segment, or a kill switch flipped on the wrong environment all take effect just as instantly as an intended change. Unlike a pull request, there's no code review step built into flipping a switch.
Approval workflows put a second person between "an editor proposed a change" and "production actually changed." It's the same four-eyes principle behind code review and change-management processes — applied to the moment that matters, not just the code that led up to it.
How it fits into your workflow
Turn on approval requirements for the environments that matter most — production, typically. From that point on, an editor's change to a protected environment doesn't take effect immediately: it opens a request, and the old configuration keeps serving traffic until an admin reviews and decides.
Submitted by an editor. Production keeps running on the old configuration until a decision lands — nothing changes just because a request exists.
An admin reviewed the diff and signed off. The change applies immediately, and it's recorded in the audit log like any other update.
Nothing applies. The requester sees the decision and the reason, and can revise and resubmit instead of guessing what went wrong.
What counts as a sensitive change
Any edit to a flag's configuration in a protected environment — updating targeting rules, changing a rollout percentage, promoting a flag from staging to production, or a bulk action touching several flags at once. Reading flag state, viewing history, and working in non-protected environments are unaffected — the gate only sits in front of writes to the environments you've chosen to protect.
Webhook and streaming subscribers can listen for the decision the same way they listen for any other flag change — see Realtime updates.