Action
The exact operation—not a vague goal such as “handle this.”
Production control · Updated August 25, 2026
Human approval is a control system.
Test the whole loop.
A button labelled “Approve” proves very little. A production gate must bind a decision to one action, one target, one payload, and one time window—then leave evidence of what actually happened.
Commercial disclosure: if our referral link is active and you later buy an eligible paid Falcon Builder plan through it, we may earn a commission. This checklist is independently written and remains usable without that link.
Step one
Map the consequence before choosing the gate.
The same model output can be low risk as a draft and high risk when it is sent, written, paid, or published.
LevelActionExamplesMinimum control
01ObserveRead records, classify, summarizeUsually no gate; log access and source.
02DraftPrepare an email, change, or recommendationReview before anything leaves the workspace.
03CommunicateSend a message, publish, notify a customerRequire a named reviewer and final payload.
04Change stateWrite a database, update CRM, change permissionsRequire scope, rollback, and expiry.
05High impactPay, delete, sign, disclose sensitive dataUse explicit approval plus an independent control.
Step two
Make the approval object reviewable.
An approver should not have to infer the hidden payload, find the target in another screen, or guess whether a decision lasts five minutes or forever.
Target
The person, record, system, account, or environment affected.
Payload
The final message, fields, amount, query, or change set.
Consequence
What becomes visible, billable, irreversible, or externally binding.
Requester
The workflow, user, policy, and reason that created the request.
Expiry
When this permission stops being valid, even if nobody responds.
Rollback
The recovery path and the point after which recovery is impossible.
Step three
Give the reviewer more than yes or no.
A binary gate often pushes legitimate corrections outside the audited path. Keep the decision and the changed payload together.
Approve
Permit this exact action, target, and payload within the stated time window.
Edit
Change the payload or scope, then bind approval to the revised version.
Reject
Stop the action and record a reason that the workflow can route or learn from.
Escalate
Move the decision to a person with the right authority or subject expertise.
Step four
Test what happens after the happy path breaks.
Run these against a harmless sandbox target. A polished approval screen is not evidence that retries, expiry, and downstream failures are controlled.
T1
Timeout
Leave the request unanswered. It should expire safely, not silently continue.
T2
Stale approval
Approve, then let the validity window close before execution.
T3
Duplicate retry
Replay the same request and confirm that one approval cannot authorize two effects.
T4
Revoked permission
Remove the executor’s access after approval but before the action runs.
T5
Changed payload
Alter one field after review and verify that the prior approval no longer matches.
T6
Partial execution
Force a downstream failure after one step succeeds and inspect recovery evidence.
01 / Proposal phase
Freeze the thing a person is judging.
Generate the action description, target, payload, consequence, expiry, and rollback plan. Assign an approval ID and hash the material payload. Nothing external happens in this phase.
02 / Execution phase
Re-check before creating the effect.
Confirm that the approval is current, the payload still matches, the approver still has authority, and the executor still has permission. Then execute once and attach the result to the same approval ID.
Step five
Require evidence after the click.
Approval evidence and execution evidence are different records. Keep both, joined by one stable identifier.
01Approval ID
One stable identifier linking the proposal, decision, and execution.
02Payload hash
Proof of which exact version was reviewed and acted on.
03Decision record
Approver, outcome, timestamp, reason, and expiry.
04Execution result
Start/end time, actor, affected target, response, and errors.
05Rollback status
Whether recovery ran, succeeded, failed, or was unavailable.
Vendor demo worksheet
Ask for one complete failure-path demonstration.
Bring a harmless test action and watch the entire sequence. Do not accept a slide, template name, or button screenshot as a substitute.
- 01
Show the exact proposal and every value the approver can inspect.
- 02
Edit one field and prove the decision binds to the revised payload.
- 03
Let a request expire, then try to execute it.
- 04
Retry the same approved operation twice.
- 05
Revoke permission between approval and execution.
- 06
Force a downstream error and inspect the joined evidence.
Falcon-specific checkpoint
What the current first-party material is sufficient to evaluate.
Falcon Builder's current homepage describes a Slack “Send and Wait for Response” example in which a teammate can Approve or Revise and unanswered requests time out. Its template library lists a support auto-responder with human approval and a Slack approval workflow.
Its MCP documentation separates read access, draft editing, workflow runs, and publish/rollback. The documentation also warns that runs can create real side effects and treats publish permission like a deployment key. Those are concrete demo targets—not a guarantee that every workflow, integration, or configuration has the same behavior.
Plan details can change. The current pricing page marks some enterprise controls as “Coming soon,” and Falcon's Terms do not promise uninterrupted, error-free, accurate, or reliable results. Verify the exact plan and control before purchase or deployment.
Primary sources