← Back to AI automation and cost control
See how it helps
Human approval steps
Adds durable human decision points to workflows with exact request binding, decision permissions and clear expiry behavior.
approval-human-tasks
Team members using this skill
When is it useful?
Use it when a process must wait for one or several people and later continue without accepting stale decisions.
What does it help you do?
- Binds decisions to workflow version and frozen payload.
- Checks live membership and prevents forbidden self-approval.
- Persists expiration and makes simultaneous decisions advance only once.
Try asking this
Implement a two-reviewer approval that expires and rejects stale clicks. Let both reviewers act at the same moment, then change the request. The workflow must advance once and reject decisions tied to the old revision.
Detailed documentation
Read the skill’s original instructions, examples and checks in their authored language.
Show less
Approval & Human Tasks
Use this skill when building human approval gates, review tasks, manual input steps, and escalation timers inside workflows.
Tamper-Proof Approval Binding
- Bind Every Approval Decision to the Exact Subject, Payload & Version:
- When a workflow reaches an
Approvalstep, snapshot the exact decision subject, frozen action parameters (payloadHash),runId,stepExecutionId,workflowVersionId, andexpiresAt. - Record who decided (
deciderUserId), in which workspace (tenantId), when (decidedAt), the decision (approved|rejected|changes_requested), and any reason/comment. - Never allow a workflow definition edit or post-request payload mutation to bypass or reuse an existing approval. If the underlying parameters change, the prior approval is invalidated.
- When a workflow reaches an
- Enforce Authorization & Separation of Duties (SoD) at Decision Time:
- Verify on the server at the moment the human clicks "Approve" or "Reject":
- The decider is an active member of the run's workspace (
tenantId). - The decider currently holds the required role/permission or valid active delegation for that approval step and value threshold.
- Self-Approval Prohibition: Unless explicitly exempted by a documented rule, the run initiator / requester cannot approve their own request (
deciderUserId !== initiatorUserId).
- The decider is an active member of the run's workspace (
- Verify on the server at the moment the human clicks "Approve" or "Reject":
Durable Expiration, Reminders & Multi-Approver Rules
- Explicit Quorum & Routing Rules:
- Define whether a multi-approver step requires First Responder (
1-of-N), Unanimous (All-of-N), or Sequential Chain (Manager -> Finance -> Legal) approval.
- Define whether a multi-approver step requires First Responder (
- Expiration & Escalation Timers:
- Persist a durable
expiresAttimer for every pending approval. - When
now >= expiresAt, transition the approval atomically toexpired(rejecting any late click with a clear conflict error) and route the workflow along its declaredexpired/escalationbranch.
- Persist a durable
- Idempotent Decision Submission:
- Guard the approval decision endpoint with atomic state transitions (
WHERE status = 'pending') so double-clicking or two approvers acting simultaneously on a1-of-Ngate cannot advance the workflow twice.
- Guard the approval decision endpoint with atomic state transitions (
Checklist
- Is the approval bound to
runId,stepExecutionId,workflowVersionId, and a frozenpayloadHash? - Does the server verify workspace membership, permission, and self-approval prohibition (
decider !== requester) at decision time? - Are approval timeouts persisted as durable timers that route cleanly to an
expiredor escalation branch? - Does atomic state checking prevent duplicate clicks from triggering double workflow resumption?
Included files 1
SKILL.md
