Approval block

The Approval block (type: "approval") pauses the run until a named approver approves or rejects the request, then continues or stops. For the plain-language guides, see Add an approval step and Approve or reject a request.

When to use it

• Sign-off on a payment, a vendor bill over a limit, or a journal entry before it is posted.
• A review point after an AI Agent step, before anything is written to the ledger.

While the step waits, the run's status is waiting_approval and the request appears in Studio under Approvals.

Configuration

Escalation Approvers has an effect only with timeoutAction: "escalate", which the editor does not set. Set it in the workflow definition. Escalation goes one level: if the escalated request also times out, the step fails.

Notification channels

If channels are set and the request reaches no approver, the request is closed and the step fails, naming why.

Decisions

• The first decision from any approver applies; other approvers' links stop working.
• In Studio, a person who is not a listed approver cannot decide, except a company owner or admin. Their decision is recorded as an override in the Audit trail.
• Approve: the step succeeds and the run continues.
• Reject: the step fails and the run stops with Approval step "<name>" was rejected. To branch on a rejection instead, set "errorHandling": { "strategy": "continue" } on the step and test decision.approved in a later Condition.
• Timeout: fail fails the step; reject records an automatic rejection by system; approve records an automatic approval by system; escalate sends a new request to escalateTo.

Output

Read the decision as {{steps.<step id>.decision.approved}}. The editor's output list shows approved, approvedBy, approvedAt and comment; the executor returns the fields above.

Example

{
  "id": "controller_approval",
  "type": "approval",
  "name": "Controller approves payment run",
  "config": {
    "approvers": ["controller@example.com", "cfo@example.com"],
    "reason": "Payment run of {{steps.build_run.result.total}} across {{steps.build_run.result.count}} vendors",
    "context": { "Pay date": "{{input.payDate}}" },
    "timeout": "2d",
    "timeoutAction": "escalate",
    "escalateTo": ["cfo@example.com"],
    "escalationTimeout": "1d",
    "reminders": { "before": ["4h"], "channels": ["email"] },
    "notifyChannels": [
      { "type": "email", "instructions": "Write a short, plain email asking the approver to review this payment run." },
      { "type": "slack", "channel": "C12345678" }
    ]
  }
}

Record a decision by API

Find pending requests with GET /api/v1/approvals (workflows:read scope). With no status filter it returns pending requests; each item's id is the approval id. Then post the decision:

curl -X POST https://workflow.loopfour.ai/api/v1/approvals/<approval id>/decide \
  -H 'x-api-key: wfk_live_your_api_key' \
  -H 'Content-Type: application/json' \
  -d '{ "approved": true, "reason": "Checked against the remittance" }'

The key needs the approvals:decide scope (workflows:write is also accepted). An API decision is recorded with decidedBy set to api_key:<key id>.

{
  "success": true,
  "data": {
    "approvalId": "3f6c2b1e-8a4d-4f1b-9c7e-2d5a6b8c9e01",
    "status": "approved",
    "decidedAt": "2026-11-12T17:04:11.000Z",
    "decidedBy": "api_key:7b1d…",
    "reason": "Checked against the remittance"
  }
}

See Runs API for the run endpoints.