Approvals and Signals

Approvals and signals are durable Program waits. They suspend the current run, release its execution process, and resume the same version-pinned run when the matching decision or event arrives. Neither wait has an implicit timeout. It remains pending until resolved or the run is canceled.

Explicit approval

Author the wait in Program source:

let decision = await_approval("Approve the release?").await;

The run detail shows Approval while parked. Submit a decision there, or use the Management API:

curl -X POST \
  "https://api.noorle.com/v1/workflows/${WORKFLOW_ID}/runs/${RUN_ID}/approval" \
  -H "Authorization: Bearer ${NOORLE_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "approved": true,
    "comment": "Release window confirmed",
    "data": {"ticket":"CHG-204"}
  }'

The decision becomes the result of await_approval. The Program decides what approval and denial mean next; a denial does not automatically select a hidden failure path. Put the wait before the consequential effect. Write a prompt that identifies the action, target, and evidence a reviewer needs.

Named signals

Use a signal when an authenticated integration knows the Workflow and run IDs and should resume the Program by name:

let event = wait_for_signal("inventory_ready").await;

Deliver it through the Management API:

curl -X POST \
  "https://api.noorle.com/v1/workflows/${WORKFLOW_ID}/runs/${RUN_ID}/signal" \
  -H "Authorization: Bearer ${NOORLE_API_KEY}" \
  -H "Idempotency-Key: ${SIGNAL_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "inventory_ready",
    "payload": {"reservation_id":"rsv_204"}
  }'

The name must match the pending wait. The payload becomes the result returned to the Program. Reuse the same Idempotency-Key when retrying the same delivery; use a new key only for a distinct event.

Approval wait versus policy gate

An authored approval wait and a capability-policy gate are different objects:

	Authored approval	Policy gate
Created by	`await_approval` in Program source	The capability reference monitor
Purpose	A business decision designed into the process	Permission to perform a particular tool call
Shown as	The run’s current `approval` wait	A pending policy approval on the run
Resolved by	Workflow approval action or `/approval`	Gate decision action or `/v1/gates/{gate_id}/decision`
Returned to Program	Approval decision payload	Tool call continues or is denied

Bound capability calls on the Workflow surface normally use the Workflow’s authored-plan policy lane. Account deny rules and the hard safety floor still apply. Use await_approval when the process itself requires human judgment.

Design limits

Approval and signal waits have no deadline parameter on the current Program surface.
A transient Agent-authored procedure cannot use either durable wait.
A signal is authenticated through the Management API. Use a callback when a third party should resume one exact wait with a bearer URL instead.
Cancel abandoned waits so they do not remain active indefinitely.

Getting Started

Platform

Built-in Capabilities

Connectors

Agents

Channels

Workflows

Knowledge & RAG

Approvals and Signals

Explicit approval

Named signals

Approval wait versus policy gate

Design limits

Next

​Explicit approval

​Named signals

​Approval wait versus policy gate

​Design limits

​Next

Explicit approval

Named signals

Approval wait versus policy gate

Design limits

Next