boundary
When Does a Workflow Need a Human Approval Gate?
Put a person on the step that spends money, changes access, sends an irreversible message, or applies a policy exception. Write who may approve, how long the run may wait, what rejection does, and what the audit record must contain. Flowspoken can make that gate visible in the step list. Connected services and credentials require separate authorization. The gate is not approval until a named person acts. Do not claim the workflow succeeded because the happy path was automated.
What this question usually means
The rewrite cluster is: where to place the gate, who the approver is, timeout, rejection path, and the audit trail. People also hope the model will “approve obviously safe cases.” That hides authority. If the action needs a person, the run waits.
This is the boundary guide: it makes authority, handoff, and the product limit explicit. Automation may draft; it may not take the authorized action by pretending the connector is already allowed.
Materials or prerequisites
Bring the action that needs judgment, the named approver or role, the timeout, the rejection behavior, and the account boundary. Bring a sample of a case that should wait and a case that should reject.
Step 1: Name the action that a person must own
Refund, access grant, customer commitment, deletion, or an exception to a written rule. If you cannot name the harm of an automatic yes, you may not need a gate — or you have not thought about the harm yet.
Step 2: Place the gate immediately before that action
Earlier gates stall harmless work. Later gates mean the action already happened. The step before the gate can draft; it cannot send.
Step 3: Define approver, timeout, and rejection
One accountable role, a clock, and a path that does not silently retry the forbidden action. Timeout should escalate or stop, not approve. Rejection should record why.
Step 4: Write the audit fields
Who was asked, what they saw, what they decided, when, and which run. An approval you cannot reconstruct is not an audit record.
Step 5: Test wait, reject, and timeout with representative data
Every workflow needs testing with representative data before wider use, including the approval path. If a connector would send the message, keep it unauthorized in the test or use a dry-run output you inspect by hand.
Verification
A reviewer can find the gated action, the approver, the timeout behavior, the rejection path, and an audit shape. No recorded run should show the gated action completing without a person. If it does, the gate is not a gate.
Limits that belong next to the gate
Connected services and credentials require separate authorization. Every workflow needs testing with representative data before wider use. Do not imply access to a service before its connector is authorized, including “the bot will just send it after approval” when send is not wired.
Do not claim a workflow ran or succeeded without run evidence. An approval design is not a completed approval. Flowspoken does not replace the named human on refunds, access, or policy exceptions.
What Flowspoken does in this workflow
Flowspoken is for readable steps with explicit approvals and failure states. Ask it to add retries and approval to a flow you described. You still name the approver and you still own the decision.
FAQ
Questions this guide is for
Can a timeout count as approval?
Not on this path. Timeout should stop or escalate. Treating silence as yes hides the owner the audit needs.
Who is the approver if the team shares an inbox?
A role is acceptable if one account or named person still appears on the audit record. “The inbox” is not a person.
Start in the workspace
Place this approval gate in the workspace
Sign in or create an account. You return to the Flowspoken conversation. Name the gated action, the approver, and the timeout, then test wait and reject before wider use.