Where the Approval Gate Belongs in an AI Workflow

Before you place a Human Review node anywhere in a workflow graph, answer one question precisely: what is the reviewer being asked to evaluate? The answer determines everything else, including where the node goes, what the payload should contain, and what the three possible decisions (approve, reject, request changes) should trigger downstream.

There are three distinct things a reviewer can be asked to evaluate, and they belong at different points in a pipeline.

Input approval: is this brief worth pursuing?

Some workflows need a human to approve the inputs before any AI processing begins. A content brief that is off-strategy, a topic that is outside scope, or a request that violates policy should be caught before an agent spends time on it. An approval gate here sits immediately after the User Interaction node that collects the brief, before any Agent Interaction node runs.

This placement is appropriate when the cost of processing a bad input is high (in time, compute, or downstream rework) and when the person submitting the input is not the same person responsible for the output. It is less appropriate when inputs are tightly constrained by the workflow form itself and bad inputs are rare.

Output approval: is this result good enough to use?

The most common placement. A reviewer evaluates what an AI agent produced and decides whether it meets the standard required to continue. This gate sits after one or more Agent Interaction nodes and before the step that uses the output: publication, delivery, API submission, or handoff to another system.

The key design question here is not just where but how many times. A single Human Review node after the final agent in a chain is the simplest pattern. Multiple review nodes, one after each major processing step, add more control but more latency. Choose based on where errors are most likely to occur and most costly to fix.

Consequence approval: is it safe to take this action?

Some workflows end with an action that cannot be undone: sending an email, publishing content, submitting a form to an external system via an API Call node. An approval gate immediately before that action is a consequence gate. It is not reviewing the quality of the content: it is authorising the act of sending it. This gate belongs as close to the irreversible action as possible, with a payload that shows the reviewer exactly what will be sent and where.

These four patterns cover the majority of real-world approval gate designs. Each is built from the same DAVE node types: Human Review for the gate itself, Routing for the branching logic, and Agent Interaction or API Call for the steps on either side.

Pattern 1: Gate after the final agent, before output is used

The most common pattern. The workflow runs all its AI processing steps first, then presents the finished output to a reviewer before doing anything with it.

Start → User Interaction → Agent Interaction → Human Review → [Approve: API Call / End] [Reject: End] [Request Changes: Agent Interaction → Human Review]

Use this pattern when the AI output is the deliverable and the reviewer's job is to certify its quality. The payload passed to the Human Review task should contain the full agent output, the original brief, and any relevant metadata. The reviewer sees everything they need to make a judgment without leaving the task detail page.

The revision loop (request changes routing back to the Agent Interaction node) is optional but common. If you include it, add a loop exit condition via a Routing node that counts iterations and routes to a rejection End node after a defined maximum, so the loop cannot run indefinitely.

Pattern 2: Gate before an irreversible action

The workflow completes all processing and review, then pauses one final time before taking an action that cannot be undone.

... → Human Review (quality) → [Approve: Human Review (send authorisation)] → API Call → End

Use this pattern when the act of sending or publishing is a separate decision from the act of approving quality. The two Human Review nodes have different payloads and may be assigned to different people: an editor approves the content, a manager authorises the send. The second gate's payload should show exactly what will be sent, to whom, and via which system.

This pattern adds latency but is appropriate for high-stakes communications, regulated outputs, or any action where the cost of an error after the fact is significantly higher than the cost of an extra review step.

Pattern 3: Gate on the input, before AI processing begins

The workflow collects a brief from a user, pauses for a human to approve the brief, then proceeds to AI processing only if approved.

Start → User Interaction → Human Review (brief approval) → [Approve: Agent Interaction → End] [Reject: End]

Use this pattern when inputs are variable and potentially out of scope, when the person submitting the brief is not accountable for the output, or when AI processing is expensive enough that bad inputs should be filtered before they consume resources. The reviewer's payload should contain the submitted brief and any relevant policy or scope criteria to evaluate it against.

Pattern 4: Automated gate with human escalation

An Agent Review node runs an automated quality check. If the check passes, the workflow continues without human involvement. If it fails, a Human Review node is triggered for human assessment.

... → Agent Interaction → Agent Review → Routing → [Pass: API Call → End] [Fail: Human Review → [Approve: API Call → End] [Reject: End]]

Use this pattern in high-volume workflows where most content is expected to pass automated checks and human review is reserved for genuine exceptions. The Routing node reads the Agent Review result and dispatches accordingly. The Human Review task payload should include both the original content and the Agent Review's findings, so the reviewer understands why the item was escalated.

This pattern keeps humans in the loop for edge cases without making them review every item. It scales well and reduces reviewer fatigue compared to routing every item through a Human Review node.

The Human Review node generates a task. That task has a payload: a JSON object passed from the workflow to the task, containing the data the reviewer needs to make a decision. The payload is the only information the reviewer sees on the task detail page, so its design is as important as the gate's placement.

A reviewer who sees only the output without the context that produced it cannot evaluate whether the output is correct. A reviewer who sees an undifferentiated dump of every workflow field will slow down and miss what matters. The payload is a design surface: treat it as one.

What a good payload includes

• The thing being approved. The content, output, or action that the reviewer is evaluating. This should be the first and most prominent item in the payload.
• The context that produced it. The original brief, the agent's instructions, the source data, or the parameters that shaped the output. Without this, the reviewer cannot judge whether the output is a correct response to the input.
• The decision criteria. If the reviewer is expected to apply a specific standard (a style guide, a compliance rule, a quality threshold), that standard should be in the payload or referenced clearly. Do not assume the reviewer knows the criteria from memory.
• Any automated findings. If an Agent Review node ran before the Human Review node, include its verdict and findings in the payload. The reviewer should not have to repeat checks the system already performed.

What a good payload excludes

• Internal system fields, IDs, and metadata that have no bearing on the review decision.
• Duplicate information that appears in multiple fields.
• Raw JSON structures that are not human-readable without parsing.

Configure the payload in the Properties Panel of the Human Review node in the Workflow Editor. The payload is stored on the node and travels with the workflow version: every instance that reaches that node will present the same payload structure, populated with that instance's runtime values.

A Human Review node produces one of three decisions: approve, reject, or request changes. Each decision should route to a distinct downstream path. The cleanest way to implement this is with a Routing node placed immediately after the Human Review node.

The Routing node is logic-only: it evaluates the decision value from the workflow context and dispatches to the correct branch without creating tasks or invoking agents. Keeping the branching logic in a Routing node, separate from the Human Review node itself, means you can change a branch condition without touching the review node configuration.

The three branches and what each should do

• Approve. Route forward to the next step in the pipeline. This might be an API Call node that publishes content, a second Human Review node for a consequence gate, or an End node that marks the workflow complete. The approve branch should be the shortest path to the intended outcome.
• Reject. Route to an End node labeled with the rejection outcome, or to a notification step that informs the submitter. Do not route a rejection back into a revision loop by default: a rejection means the content is not suitable for revision in the current form. If you want to allow resubmission after a rejection, make it a deliberate design choice with a clear path back to a User Interaction node where the submitter can revise the original brief.
• Request changes. Route back to an earlier node for revision. The most common target is the Agent Interaction node that produced the output, so the agent can revise it based on the reviewer's comment. Always include a loop exit condition: a Routing node that counts iterations and routes to a rejection End node after a defined maximum number of revision cycles.

The reviewer's comment, entered in the optional Comment field on the task detail page, is passed into the workflow context when the decision is submitted. Configure the revision branch to include that comment in the agent's next invocation, so the agent has explicit feedback to act on rather than regenerating the same output.

Notification configuration

Each Human Review node in the Workflow Editor has a Notifications section in the Properties Panel. The default mode follows the workspace rule for task.assigned, set under Settings, then Notifications, then Events. For high-frequency review steps, switch to No notification to avoid alert fatigue. For steps that require a specific audience beyond the default assignee, switch to Custom audience and select from task assignee, instance owner, instance participants, or workspace admins. The setting is stored on the node and travels with the workflow version.

The approval gate is one of the most frequently misconfigured elements in AI workflow design. These are the mistakes that appear most often and what to do instead.

Placing the gate too late

A gate that sits after an API Call node or after content has been published is not a gate: it is a post-mortem. If the action is irreversible, the gate must come before it. Trace every execution path through your workflow graph and confirm that every irreversible action is preceded by a Human Review node on every path that leads to it.

Placing the gate too early

A gate that asks a reviewer to approve a rough first draft, before any AI refinement or automated checking, wastes reviewer time and produces lower-quality feedback. Run Agent Interaction nodes first to produce a polished draft, then Agent Review nodes to catch obvious issues automatically, then Human Review for the judgment calls that require a person. Reserve human attention for decisions that genuinely require it.

A revision loop with no exit

A request-changes branch that routes back to an Agent Interaction node without a maximum iteration count will loop indefinitely if the agent never produces an output the reviewer approves. Always add a Routing node that counts iterations and routes to a rejection End node after a defined maximum. The node and edge counter in the top-right corner of the Workflow Editor canvas helps you audit the graph for loops that lack exit conditions.

An empty or unhelpful payload

A task with an empty payload (shown as {} on the task detail page) gives the reviewer nothing to evaluate. This is a workflow configuration issue: the Human Review node's payload was not configured in the Properties Panel. Check the node configuration and ensure the payload includes the content, context, and decision criteria the reviewer needs.

No comment on a rejection

When a reviewer rejects or requests changes without adding a comment, the workflow owner and any downstream step have no explanation for the decision. Encourage reviewers to use the Comment field consistently for non-approval decisions. The comment is passed into the workflow context and can be included in the next agent invocation as explicit revision feedback. A comment-free rejection is a missed opportunity to improve the next iteration.

Dangling paths after the gate

A Human Review node with three possible outcomes (approve, reject, request changes) that connects to only one or two downstream nodes leaves one or more outcomes with no path. At runtime, a workflow instance that reaches a decision with no matching outgoing edge will hang. Confirm that every Human Review node has outgoing edges for all three decision values, either via a Routing node or directly, before saving a workflow version.