Summary

An approval gate pauses a DAVE workflow and routes it through a named human reviewer before execution continues. This guide walks through placing a Human Review node, wiring its three outgoing paths, and configuring the reviewer assignment and notifications.

The steps

1
Open the Workflow Editor
From the sidebar, navigate to Workflows. Find the workflow you want to add an approval gate to and click its name to open the detail page. From there, click the button to open the Workflow Editor.
The editor opens in a three-panel layout: the Node Palette on the left, the canvas in the center, and the Properties Panel on the right (visible when a node is selected).
If the workflow has no saved versions yet, the canvas will be blank. Start by placing a Start node before adding the approval gate. If you are adding a gate to an existing workflow, the current graph loads automatically.
Do this
- Navigate to Workflows in the sidebar.
- Click the workflow name to open its detail page.
- Click the Workflow Editor button to open the editor.
- Confirm the existing graph is visible on the canvas, or begin with a Start node if the canvas is blank.
Example
A team has a content generation workflow: Start, then Agent Interaction (generates a draft), then End. They want to add an approval gate between the Agent Interaction node and the End node so a human must approve the draft before the workflow completes.
Best practice
- Only Admin and Curate roles can open the Workflow Editor, add nodes, connect edges, and save versions. If you do not see the editor option, ask your administrator to assign you one of these roles.
- The editor does not auto-save. Any changes you make are not persisted until you click Save Version. Do not navigate away without saving.
2
Drag a Human Review node onto the canvas
In the Node Palette on the left, locate the Human Review node. It is listed with an amber color and an Eye icon. Grab its grip handle and drag it onto the canvas, placing it at the point in the workflow where you want the approval gate to sit.
When you release the mouse, the Human Review node appears on the canvas with its default label "Human Review". It has a target handle (top circle, receives incoming edges) and a source handle (bottom circle, sends outgoing edges).
If you are inserting the gate into an existing workflow between two connected nodes, you will need to delete the existing edge between them first. Click the edge to select it, then press the Delete key. The two nodes are now disconnected and ready to be rewired through the Human Review node.
Do this
- Find Human Review (amber / Eye icon) in the Node Palette.
- Drag it onto the canvas at the desired position in the workflow.
- If inserting between two existing nodes, click the edge between them and press Delete to remove it first.
Example
The team drags a Human Review node onto the canvas and positions it between the Agent Interaction node and the End node. They click the existing edge between those two nodes and press Delete to remove it, leaving the Human Review node ready to be connected.
Best practice
- Place the Human Review node visually between the upstream and downstream nodes it connects. The canvas is freeform, so positioning is for readability only, but a clear left-to-right or top-to-bottom layout makes the graph easier to follow for future editors.
- Rename the node immediately after placing it. The default label "Human Review" is not descriptive. Click the node to open the Properties Panel and change the Label to something specific, such as "Editorial Director Approval" or "Compliance Sign-off".
3
Connect the upstream node to the Human Review node
Hover over the source handle (bottom circle) of the node that runs immediately before the approval gate. The handle highlights when you hover over it. Click and drag from that source handle to the target handle (top circle) of the Human Review node. Release the mouse over the target handle to create the edge.
An animated line appears connecting the two nodes, indicating the execution path: when the upstream node completes, execution flows into the Human Review node and pauses there.
Connections must always go from a source handle (bottom) to a target handle (top). You cannot connect source-to-source or target-to-target. If the connection does not form, check that you are starting from the bottom of the upstream node and releasing on the top of the Human Review node.
Do this
- Hover over the source handle (bottom circle) of the upstream node.
- Click and drag to the target handle (top circle) of the Human Review node.
- Release to create the edge.
- Confirm an animated line connects the two nodes.
Example
The team hovers over the bottom handle of the Agent Interaction node, drags to the top handle of the Human Review node, and releases. An animated line now connects them. Execution will flow from the agent into the approval gate.
Best practice
- If the canvas is zoomed out and the handles are small, zoom in using the + button in the controls overlay or the mouse wheel before attempting to connect. Precise handle targeting is easier at higher zoom levels.
- After connecting, click the edge to confirm it is selected and inspect it. If it does not appear to connect the correct nodes, delete it and try again.
4
Wire the three outgoing paths: Approve, Reject, Request Changes
The Human Review node has three possible outcomes: Approve, Reject, and Request Changes. Each outcome must route to a downstream node. A Human Review node with unconnected outcomes will leave the workflow with dangling paths that can cause instances to hang at runtime.
To wire each path:
1. Click the Human Review node to open the Properties Panel.
2. In the Input / Output Ports section, review the available output ports. Each decision outcome corresponds to a named output port.
3. For each port, drag an edge from the Human Review node's source handle to the appropriate downstream node.
Typical downstream targets:
- Approve: connect to the next step in the workflow (for example, an End node for a simple gate, or the next Agent Interaction node in a longer pipeline).
- Reject: connect to an End node with a rejection outcome, or to a notification step, or back to the workflow owner for manual intervention.
- Request Changes: connect back to an earlier node (for example, an Agent Interaction node that regenerates the content) or to a User Interaction node that collects revision instructions.
If your workflow does not yet have the downstream nodes you need, drag them onto the canvas now and connect them before saving.
Do this
- Click the Human Review node to open the Properties Panel.
- Review the output ports in the Input / Output Ports section.
- Connect each output port to an appropriate downstream node: Approve to the success path, Reject to the rejection path, Request Changes to the revision path.
- Ensure every path leads to an End node. No path should be left dangling.
Example
The team connects the Approve port to the existing End node. They add a second End node labeled "Rejected" and connect the Reject port to it. For Request Changes, they connect back to the Agent Interaction node so the agent regenerates the draft based on the reviewer's comment. All three paths now lead to a defined outcome.
Best practice
- Every path must lead to an End node. Dangling paths (nodes with no outgoing edge and no End node) may cause instances to hang at runtime.
- Use the Information node (indigo / Info icon) to annotate the purpose of each outgoing path on the canvas. Information nodes do not affect execution but make the graph self-documenting for future editors.
- If the Reject and Request Changes paths are identical in your workflow (both lead to the same outcome), you can connect both ports to the same downstream node. The routing logic is still distinct: the reviewer's decision is recorded separately regardless of where the paths converge.
5
Configure the reviewer assignment and notifications
With the Human Review node still selected (or click it to reselect), use the Properties Panel on the right to configure who receives the review task and how they are notified.
User Assignment
Open the User Assignment section in the Properties Panel. Specify the user IDs or roles that should receive the review task. Only users with the Admin or Use role can complete tasks in the Task Inbox. Assign the review to a specific user for a named approval gate, or to a role for a pool-based review where any qualifying user can complete the task.
Notifications
Open the Notifications section. Choose one of three modes:
- Use workspace rule (default): follows the workspace-level notification setting for task assignment events. Use this for most approval gates.
- No notification: the step never sends a notification email, even if the workspace rule is on. Use this for high-frequency intermediate approval steps that would otherwise generate excessive email volume.
- Custom audience: this step notifies its own defined audience instead of the workspace rule. Options include the task assignee, the instance owner, instance participants, and workspace admins. If you select Custom audience and clear all options, the step sends nothing. The panel warns you rather than failing quietly at runtime.
For a high-stakes final approval gate, Custom audience with the task assignee and instance owner selected is a reliable default: the reviewer is always notified, and the person who triggered the workflow knows the gate has been reached.
Do this
- Click the Human Review node to open the Properties Panel.
- Open User Assignment and specify the reviewer by user ID or role.
- Open Notifications and select the appropriate mode: Use workspace rule, No notification, or Custom audience.
- If Custom audience is selected, choose at least one recipient option to avoid a silent no-notification state.
Example
The team opens User Assignment and assigns the review to the Editorial Director's user ID. They open Notifications, select Custom audience, and check the task assignee and instance owner options. The Editorial Director will receive an email when the task is created, and the workflow initiator will be copied.
Best practice
- Assign to a specific user for accountability-sensitive gates where a named decision-maker is required. Assign to a role for operational gates where any qualified team member can approve.
- The notification setting is stored on the node and travels with the workflow version. If you publish a new version, the notification configuration carries forward. Older versions keep the behavior they were saved with.
6
Save the version and test
Click Save Version in the top-right corner of the editor. The editor serializes the full graph (all nodes, edges, labels, configs, and positions) into a new immutable workflow version. The previous version is preserved: saving is non-destructive.
After saving, test the approval gate by triggering a new workflow instance. When execution reaches the Human Review node, navigate to Tasks in the sidebar and confirm a task of type human_review appears in the Task Inbox for the assigned reviewer. Open the task and verify the Payload section contains the expected content from the upstream step.
Submit a test decision (Approve, Reject, or Request Changes) and confirm the workflow routes to the correct downstream node for each decision. Repeat for all three decision paths before putting the workflow into production use.
Do this
- Click Save Version in the top-right corner.
- Confirm the version is saved and the version list updates.
- Trigger a test workflow instance.
- Navigate to Tasks in the sidebar and confirm a human_review task appears for the assigned reviewer.
- Test all three decision paths: Approve, Reject, and Request Changes.
Example
After saving, the team triggers a test instance of the "Content Review" workflow. They navigate to Tasks and see a new task labeled "Editorial Director Approval" assigned to the Editorial Director. They open the task, review the payload, click Approve, and confirm the workflow routes to the End node. They repeat with Reject and Request Changes to verify all three paths work correctly.
Best practice
- Test all three decision paths, not just the happy path. A misconfigured Reject or Request Changes edge is not visible until a reviewer actually uses that decision in production.
- Each click of Save Version creates a new version. If you discover a problem during testing, fix it in the editor and save again. The previous version remains available if you need to roll back.
- Use a test user account with the Use role to verify the Task Inbox experience from the reviewer's perspective. Admin and Curate users see the editor; Use-role users see the Task Inbox. The reviewer experience is what matters for the gate to work in practice.

What an approval gate is in DAVE

An approval gate is a Human Review node placed at a point in a workflow where a human decision is required before execution can continue. It is not a notification, a log entry, or an automated check. It is a hard pause: the workflow stops, a task is created in the reviewer's Task Inbox, and nothing downstream runs until the reviewer submits a decision.

The Human Review node (amber, Eye icon) is one of DAVE's ten node types. It creates a review task with three possible decisions: Approve, Reject, and Request Changes. Each decision routes execution to a different outgoing path. A well-designed approval gate has all three paths connected to meaningful downstream nodes: the Approve path continues the workflow, the Reject path handles the failure case, and the Request Changes path routes to a revision step.

The gate is enforced at the platform level. There is no way for a workflow to skip a Human Review node or proceed without a decision. The task must be completed by an assigned reviewer before the instance can advance.

This is the mechanism DAVE provides for human-in-the-loop governance: not a convention, not a documentation note, but a structural constraint built into the workflow graph.

When to use an approval gate and where to place it

An approval gate is the right choice when a human decision is required before the workflow continues. The most common placement patterns:

After AI content generation

Place a Human Review node after an Agent Interaction node when the generated content will be published, sent to a customer, or used to make a consequential decision. The reviewer sees the agent's output in the task payload and approves, rejects, or requests changes before anything downstream acts on it.

Before an external API call

Place a Human Review node before an API Call node when the API call has an irreversible effect: sending an email, submitting a form, posting to an external system. The gate gives a human a chance to verify the payload before it leaves the system.

At a compliance checkpoint

Place a Human Review node at any point where a named human sign-off is required by policy, contract, or regulation. The task completion record (reviewer identity, decision, timestamp, optional comment) is the evidence that the sign-off occurred. DAVE's audit trail captures this for SOC 2 and GDPR compliance modes.

At the end of a multi-step pipeline

Place a Human Review node as the final step before an End node when the workflow produces output that requires final approval before it is considered complete. This is the simplest approval gate pattern: the entire pipeline runs, a human reviews the result, and the workflow ends on Approve or routes to a revision loop on Request Changes.

Where not to use it

An approval gate creates a task that must be manually completed. For high-frequency, low-stakes intermediate checks, an Agent Review node (automated quality check) is more appropriate. Reserve Human Review for decisions that require human judgment, accountability, or documented sign-off.

Designing the three outgoing paths

The Human Review node has three outgoing decision paths. Each must be connected to a downstream node. Leaving any path dangling can cause workflow instances to hang when a reviewer makes that decision at runtime.

The Approve path

The simplest case: connect Approve to the next step in the workflow. For a final approval gate, that is an End node. For a mid-pipeline gate, it is the next Agent Interaction, API Call, or other functional node.

The Reject path

The Reject path handles the case where the content is fundamentally unacceptable and cannot be revised into an acceptable state. Common destinations: a dedicated End node with a rejection label, a notification step that alerts the workflow owner, or a User Interaction node that collects instructions for a manual restart. Avoid routing Reject back into the same generation loop that produced the rejected content: if the content was wrong enough to reject, the same agent with the same prompt is likely to produce the same result.

The Request Changes path

The Request Changes path handles the case where the content is on the right track but needs specific revision. Common destinations: back to an Agent Interaction node (the reviewer's comment in the task payload gives the agent revision instructions), or to a User Interaction node that collects more specific guidance before re-invoking the agent. This creates a revision loop: generate, review, revise, review again, until the reviewer approves.

When designing a revision loop, consider adding a Routing node to count iterations and break out of the loop after a defined number of attempts. A loop with no exit condition can run indefinitely if the agent never produces output the reviewer accepts.

Using a Routing node to simplify branching

If the Reject and Request Changes paths share some steps before diverging, use a Routing node (purple, GitFork icon) to handle the branching logic. The Routing node is logic-only: it evaluates conditions and routes execution without creating tasks or invoking agents. It keeps the Human Review node's outgoing connections clean and separates routing logic from functional steps.

Who can build and who can complete an approval gate

Two different role sets are involved in an approval gate: the people who design it and the people who complete it. DAVE ships with six default tenant roles: Admin, Create, Curate, Use, Reporting, and Financial. All roles are editable by your administrator.

Building the gate: Workflow Editor access

Only Admin and Curate roles can open the Workflow Editor, add and remove nodes, connect edges, edit node properties, and save new versions. Create, Use, Reporting, and Financial roles cannot access the editor.

Action	Admin	Curate	Others
Open Workflow Editor	Yes	Yes	No
Add / remove nodes	Yes	Yes	No
Connect / disconnect edges	Yes	Yes	No
Edit node properties	Yes	Yes	No
Save a new version	Yes	Yes	No

Completing the gate: Task Inbox access

Reviewers who complete Human Review tasks need access to the Task Inbox. Task access requires the Admin or Use role. Assign reviewers the Use role if they should be able to complete tasks but should not have access to the Workflow Editor or agent configuration.

A reviewer with only the Curate role can open the Workflow Editor and see the Human Review node in the graph, but Curate is not listed as a task-completion role. Assign Use to reviewers who only need the Task Inbox.

Frequently asked questions

Can I have more than one approval gate in a single workflow?

Yes. You can place multiple Human Review nodes in a single workflow. Each creates its own task when execution reaches it. Gates can be sequential (one after another) or on separate branches of a conditional path. Each gate must have all three outgoing paths connected.

What happens if the reviewer does not complete the task?

The workflow instance remains paused at the Human Review node until the task is completed. There is no automatic timeout or escalation built into the node itself. If you need timeout behavior, design it using a Routing node that checks a due date field, or handle escalation outside the workflow through your team's operational process.

Can the same person who triggered the workflow approve it?

Yes, if they are assigned to the review task and have the appropriate role. Whether this is appropriate depends on your governance requirements. For compliance-sensitive gates where self-approval is a risk, assign the review to a different user or role than the one that triggers the workflow.

Can I add an approval gate to a workflow that is already running instances?

Yes. Adding a Human Review node and saving a new version does not affect instances that are already running: they continue on the version they started with. New instances triggered after the save will use the new version with the approval gate. Existing instances are not interrupted.

What does the reviewer see in the Task Inbox?

The reviewer sees a task of type human_review in their Task Inbox. The task detail page shows the task label (the Human Review node's label from the Workflow Editor), the Payload section (the workflow data accumulated up to that point, including any content generated by upstream agent nodes), and the decision panel with Approve, Reject, and Request Changes buttons. The reviewer can add an optional comment before submitting their decision.

Do I need a Routing node between the Human Review node and its downstream nodes?

Not always. If each decision path leads directly to a single downstream node, you can connect the Human Review node's output ports directly to those nodes without an intermediate Routing node. Use a Routing node when you need to apply additional conditional logic after the human decision, or when multiple decision paths share some steps before diverging.