Require approval for production changes

Production changes deserve a second pair of eyes. This is built in: Developers can’t write production-class environments directly, but they don’t file tickets either — they propose the change in place, and any second teammate applies it.

There’s nothing to turn on. If your environment is production-class and your team has Developers, this is already how it works.

Proposing a change

As a Developer, make the change you want in a production environment — a toggle, a rules edit — and the dashboard offers to propose it instead of applying it. Add your reasoning if it needs any, and submit. The flag itself doesn’t move yet.

Approving one

Any teammate who’s a Developer or above — except the person who proposed it — reviews the pending proposal and approves it, which applies it on the spot. Pending proposals surface in the dashboard’s approvals inbox, so keep an eye on the bell; the inbox is the notification (there’s no email nudge).

Two rules hold, always:

• Nobody approves their own proposal. That’s enforced per person, not per role — an Admin can’t self-approve either.
• The audit log names both people on every applied proposal: who proposed, who approved, and what changed.

What this is — and isn’t

It’s peer review, not hierarchy review: two Developers together can change production, which is the point — no single person changes it alone from below Admin. Worth knowing as you set expectations:

• Admins and Owners still write production directly. The proposal path is the Developers’ route in, not a gate on everyone. There’s currently no setting that forces approvals on Admins too.
• Approval is one person, not a quorum.

If a proposal is wrong, the reviewer simply doesn’t approve it — and the proposer can make a fresh one when the shape is right.

Where to next

• Roles and safety — the full picture this sits in
• Export the audit log — where both names end up
• Schedule a change — the other production-safety tool