Decide on an execution that waits for a person

Read the requests for approval, approve or reject one, and know what happens when nobody decides in time.

3 min read

An approval is a request for a person's decision. An execution that reaches a Require Approval node stops there and waits until somebody approves or rejects it, or until its time runs out. This page is about the approvals page of the console.

Where the approvals are

Open Approvals. The tabs Pending, Approved, Rejected and Expired list the requests of the project chosen in the header. The Pending tab reads the list again every 30 seconds; Refresh reads it at once.

A row names the flow and the operation, the note the author of the flow left on the node, the node, and when the decision was asked for. A pending row says how long is left to decide; a decided one says who decided and when. Press a row to open its execution.

The page opens for whoever has the management:read permission. Approving and rejecting need management:write: in the console the roles Owner and Admin have it. Without it the buttons are not shown.

Approve or reject

1. Choose the request

On the Pending tab find the row and press Approve or Reject.

2. Give a reason

A window asks to confirm. A reason is optional: it is kept with the approval and shows in the trace of the execution.

3. Confirm

Press Approve or Reject in the window. The row leaves the Pending tab.

  • Approve sends the execution out of the node through the Approved port, and it goes on as the flow says, a model call included.

  • Reject sends it through the Rejected port. Nothing is charged for the model call it waited for.

  • The decision does not move the execution at once: it goes on within a minute.

Nothing is held while an execution waits. The money is held when the execution reaches its model call, after the decision, by a new estimate.

When nobody decides

The author of the flow sets on the node how long a decision may take; a new node gives 24 hours. When that time passes, the request becomes expired and the execution leaves through Rejected, as if it had been rejected. A pending row whose time has passed offers no buttons.

A request whose execution has ended — closed after it waited too long, for one — cannot be decided either. Over the API such a decision is refused with approval_expired, and a request somebody else has just decided with approval_already_decided. The console then reads the list again.

A request from a model node

A row can also come from a AI Model node whose overrun policy asks a person to approve a call that came out dearer than its hold. Such a row names the model node, and its note, written by Slen, gives the new estimate of the call and the hold it had. A new model node has no overrun policy, and a policy that a node has practically never fires — the row of overrun_approval_required in Error codes says why. AI Model describes the policy.

  • Approve lets the model call go on. Its hold was given back when the approval was asked for, so the call takes a new one.

  • Reject, or no decision within 24 hours, refuses the call with overrun_stopped. The execution leaves the model node through its Deny port, and ends as rejected when nothing is connected there.

Over the API and in webhooks

  • An API key with management:write decides with POST /v1/approvals/{id}/approve or POST /v1/approvals/{id}/reject; its row then says that an API key decided.

  • The webhook event approval.requested is sent when an execution starts to wait, and approval.decided when the request is approved, rejected or expired — Webhooks.

  • The audit log records each approval and rejection.

Where to go next

  • Webhooks — be told of a request without opening the console.

  • Require Approval — the node that asks for a decision: its settings and what it leaves for the nodes below.

  • Ports and branching — where the two branches of the node lead.

  • Error codes — every code of the API, what it means and what to do about it.

  • Approvals — the same requests over the API.