I’m comfortable automating a lot, but some actions are risky enough that I want a person to sign off first. How do I build approval gates for high-risk actions in 3B? I’m curious how the workflow pauses, how someone approves or rejects, and how it continues based on that decision. Examples of how people set this up would be really welcome.
Knowing which actions deserve a human in the loop is half the battle.
Here’s the shape of an approval gate. The workflow runs up to the risky action, then pauses and waits. It sends someone a request to approve or reject, and it does not proceed until it hears back. When the decision comes in, the workflow reads it and branches: approved runs the action, rejected skips it and handles the fallout. So the pattern is always three parts: pause and ask, wait for a human decision, then continue based on that decision.
How the pause and ask works. At the gate, the workflow sends the approver everything they need to make the call: what’s about to happen, to what, and why the workflow thinks it should. The more context you pack in here, the better the decision and the faster it comes. The ask itself is usually one of two styles. Either a message with approve and reject actions in a tool your team already lives in, like Slack or email, or a small approval page the person opens and clicks through. Both come down to the same thing: a way for a human to send a yes or no back into the workflow.
How it waits and resumes. The workflow holds at the gate until the response arrives, then that response comes back in and drives the branch. Approved, it proceeds to the action. Rejected, it takes the other path.
How it continues. On approve, run the high-risk action, then ideally confirm back to the approver that it’s done. On reject, don’t just stop silently: log the decision, and notify whoever raised the request that it was declined and why. Either way you’ve now got a clean record of who decided what.
A few examples of how people set this up:
- Production or infrastructure changes. A workflow prepares a change, posts the details to a Slack channel with approve and reject buttons, and only applies it once a team lead clicks approve.
- Offboarding or access revocation. Before disabling accounts or pulling permissions, the workflow routes an approval to the manager or IT with the user and exactly what will be removed.
- Security response actions. An enrichment workflow decides an endpoint should be isolated or an IP blocked, but instead of acting automatically it asks an analyst to confirm, so a false positive doesn’t take something down.
- Spend or outbound comms. Anything above a dollar threshold, or a message going to a customer, pauses for a manager to sign off before it goes out.
A couple of things worth building in. Add a timeout so a request that sits unanswered doesn’t hang forever: after some window, escalate to a backup approver or take a safe default like reject. Capture who approved and when, since that record is often the whole point of the gate. And make the action idempotent where you can, so a resume can’t accidentally fire it twice.
Short version: the workflow runs up to the risky step, pauses and sends a human an approve or reject request with full context, waits for the response, then branches to run the action or skip it. Add a timeout with escalation, log who decided, and confirm the outcome back to the requester.