What it does

An Approval task pauses a workflow run until selected team members approve or reject. Use it when an automation should not move past a step without a human decision — for example, sending a high-value invoice, posting public content, or releasing payments.

How a paused run behaves

When execution reaches the Approval task the run status changes to paused and the task status to pending_approval. Every assignee receives an email with an Approve link, a Reject link, and a deep link to the run page. Decisions can also be recorded directly from the run page (a popup appears when arriving via the email link, and approve/reject buttons stay embedded in the run overview).

Settings

Assignees – Pick one or more team members from the Manage approvers modal. The run-time assignee list is captured onto the task run when the email is sent, so changing team membership later does not affect in-flight runs.
Minimum approvals – Number of approvals required to resume the run. Capped at the number of selected approvers — if only one approver is selected the value locks at 1.
Email subject and message – Optional. Both fields accept the standard {{$trigger.<triggerId>.<fieldKey>}} and {{$task.<taskId>.outputs.<fieldKey>}} placeholders. Type {{ in either field to open the placeholder picker. Values are resolved against the live run just before the email is sent, so approvers see real context (order id, amount, customer name, etc.) — not the literal template.
Allow approving without sign-in – Off by default. When enabled, the Approve / Reject buttons in the email link to a public approval page that doesn't require a FlowFn session. When disabled, the buttons link to the dashboard run page, which requires sign-in before the approval modal renders.
Link valid for (days) – Validity window of the HMAC token embedded in the email links. Defaults to 14 days; clamped to 1–90. Shorter windows tighten security; longer windows survive long weekends and time-off.

Approval tasks are never optional — gating execution on a human decision conceptually requires the gate to be enforced. The Optional-task toggle is hidden for approval nodes, and the engine ignores is_optional for them defensively, in case legacy data has it set.

Approval and rejection logic

Once the number of approvals reaches the minimum, the task is marked succeeded and the run resumes from the approval task's next step.
Any assignee can reject. The run only fails when enough rejections have come in that the threshold can no longer be reached — until then the run keeps waiting on the remaining assignees.
Each assignee can decide once; subsequent clicks on the same link are silently ignored.

Email links and access modes

Every approval email is signed with a per-decision token. The validity window is the Link valid for (days) setting (default 14 days). Where the token lands the assignee depends on the Allow approving without sign-in setting:

Dashboard mode (default) – The Approve / Reject buttons in the email open /dashboard/workflows/<id>/runs/<id>?approve_task=...&approve_token=.... The assignee must sign in to FlowFn before the approval modal appears; the token is then used to authorise the decision call. The dashboard route also lets the assignee inspect the full run (inputs, outputs, logs) before deciding.
Public mode – The Approve / Reject buttons in the email open /approve/workflow/<runId>/<taskRunId>?token=.... This is a standalone page outside the dashboard; the HMAC token in the URL is the only authorisation. Useful when approvers don't have a FlowFn account on the device reading the email (mobile, alternate browser). Agent approvals use the parallel route /approve/agent/<approvalId>?token=....

The "Open the workflow run" link in the email always points at the dashboard, regardless of mode — public mode only changes where the Approve / Reject buttons themselves land. Signed-in assignees can also approve directly from the run-detail page in the dashboard at any time without needing the email link.

Outputs

On approval the task emits the following outputs (available to downstream tasks via $task.<id>.outputs.*):

approved – Boolean. Always true when the task succeeds.
approvals – Array of { user_id, email, name, status, decided_at, comment } for each assignee.

Best practices

Keep the message short and include the key facts (amount, recipient, link to source data) so approvers can decide without opening other tools — placeholders make that easy.
Use a minimum approval count of 2+ for high-impact actions; the run still resumes the moment the threshold is met, even if other assignees have not responded.
Pair Approval tasks with a Template task above them so the approval email body can include a rendered summary of the run via a placeholder.
Reach for public mode for routine ops (faster decisions, fewer dropped emails) and keep dashboard mode for sensitive workflows (payouts, customer comms, anything regulated) where the extra sign-in step is worth the friction.

For the broader list of node types, see Workflow Task Types. For validation requirements, see Workflow Node Rules and Validation.

Approval Tasks: Human Sign-off