Example Workflow: Invoice Approval

Build this workflow in the Workflow Editor by dragging nodes from the Node Palette onto the canvas in the order below, connecting each node's source handle (bottom circle) to the next node's target handle (top circle), and configuring each node in the Properties Panel. Every path must lead to an End node.

1. Start (green / Play icon)
   The entry point. Every workflow requires exactly one Start node. Execution begins here. No configuration required beyond the label. Suggested label: "Start".
2. User Interaction (blue / User icon)
   Pauses the workflow and creates a task in the submitter's Task Inbox. The submitter uploads or pastes the invoice details: vendor name, invoice number, line items, total amount, due date, and any supporting notes. The workflow resumes when the user submits their input. Suggested label: "Submit Invoice". In the Properties Panel, set User Assignment to the accounts payable submitter or the role responsible for invoice intake. Set Notifications to alert them when the task is created.
3. Agent Interaction (purple / Bot icon)
   Invokes an AI agent automatically to extract and validate the invoice data submitted in the previous step. The agent checks for completeness (all required fields present), consistency (line items sum to the stated total), and known vendor match against any reference data in the workflow context. It writes a structured summary and a validated total amount field to the workflow payload. No human involvement at this step. Suggested label: "Extract and Validate Invoice". In the Properties Panel, assign the agent configured for invoice data extraction and select the appropriate model.
4. Routing (purple / GitFork icon)
   A logic-only node that reads the validated total amount field written by the Agent Interaction node and routes execution to the correct approval tier. No agent is invoked; no task is created. Suggested label: "Route by Amount". Configure two output ports in the Routing Configuration section of the Properties Panel:
   • Port: standard_approvalrule: total amount is below your defined threshold (for example, below a value your finance policy specifies). Priority 1.
   • Port: senior_approvalrule: total amount is at or above that threshold. Priority 2.
   Add a default port as a catch-all for cases where the amount field is missing or unparseable, connecting it to an End node labeled "Validation Error".
5. Human Review (amber / Eye icon)
   Creates a review task in the assigned approver's Task Inbox. The approver reads the invoice summary in the task payload and chooses one of three decisions: Approve, Reject, or Request Changes. The workflow branches on the decision (see Outgoing Paths below). This node is used for both approval tiers: place two instances of it on the canvas, one connected from the standard_approval port and one from the senior_approval port, and configure each with the appropriate approver assignment.
   • Standard Approval instanceSuggested label: "Manager Approval". Assign to the line manager or finance manager role. Set Notifications to Custom audience: task assignee and instance owner.
   • Senior Approval instanceSuggested label: "Director Approval". Assign to the finance director or CFO role. Set Notifications to Custom audience: task assignee and instance owner.
6. API Call (cyan / Zap icon)
   Calls your external payment or ERP system to record the approved invoice and initiate payment. This node is reached only after an approver submits an Approve decision. Configure the API Configuration section in the Properties Panel with the Method (POST or PUT), the URL of your payment system endpoint, any required headers (Authorization, Content-Type), and a body template that maps the invoice fields from the workflow payload into the request. Map the response status back into a workflow field for downstream reference. Suggested label: "Submit to Payment System".
7. End: Approved and Submitted (red / Square icon)
   Terminal node for the successful path. Execution reaches this node after the API Call completes. The workflow instance closes with a successful outcome. Suggested label: "Approved and Submitted".
8. End: Rejected (red / Square icon)
   Terminal node for the Reject path from either Human Review node. The invoice is declined. Suggested label: "Rejected". Optionally insert a User Interaction node before this End node to notify the original submitter of the rejection and collect the approver's reason.
9. End: Returned for Revision (red / Square icon)
   Terminal node for the Request Changes path, or the start of a revision loop. If the approver requests changes, execution can route back to the User Interaction node (Step 2) so the submitter can correct and resubmit the invoice, re-entering the validation and approval steps. Alternatively, route to this End node if your policy requires a fresh submission rather than an in-flight correction. Suggested label: "Returned for Revision".

From the Routing node (Route by Amount)

From each Human Review node (Manager Approval and Director Approval)

Both Human Review nodes (Manager Approval and Director Approval) share the same three outgoing paths and can connect to the same API Call node on the Approve path. You do not need two separate API Call nodes: both approval tiers converge on a single submission step.

Every path must lead to an End node. Check the canvas using the Fit View button before saving to confirm no path is left dangling.

The tiered approval pattern is the structural core of this workflow. It uses one Routing node to make the tier decision automatically, and two Human Review nodes to handle the two approval tiers independently. Here is why each element is needed and how they work together.

Why a Routing node, not a Human Review node, makes the tier decision

The tier decision (standard vs. senior approval) is not a judgment call: it is a rule applied to a number. The Routing node is the right tool because it evaluates a field value against a defined criterion and routes execution without creating a task or invoking an agent. Using a Human Review node for this decision would require a human to manually decide which tier applies, introducing delay and inconsistency. The Routing node applies the rule instantly and consistently on every instance.

Why two Human Review nodes instead of one

Each Human Review node is configured with a specific User Assignment (the manager for standard approvals, the director for senior approvals). A single Human Review node cannot dynamically assign to different users based on the amount tier without additional complexity. Two nodes, each pre-configured for its tier, is simpler, more readable on the canvas, and easier to modify independently if approval policies change.

Converging on a single API Call node

Both Human Review nodes' Approve paths connect to the same API Call node. This convergence is intentional: the payment submission logic is identical regardless of which tier approved the invoice. A single API Call node is easier to maintain than two identical nodes. If the payment endpoint changes, you update one node.

Adding a third tier

If your policy has three approval tiers (manager, director, board), add a third output port to the Routing node and a third Human Review node. Connect the third port to the third Human Review node and connect its Approve path to the same API Call node. The Routing node's priority ordering ensures the correct tier is selected.

Three groups interact with this workflow: the builders who design it, the submitters who initiate it, and the approvers who review it. DAVE ships with six default tenant roles: Admin, Create, Curate, Use, Reporting, and Financial. All roles are editable by your administrator.

Building the workflow

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

Submitting invoices: Task Inbox access

The User Interaction node (Submit Invoice) creates a task in the submitter's Task Inbox. Submitters need Task Inbox access. Assign them the Use role if they should only interact with tasks and not access the Workflow Editor or agent configuration. The Use role is the right fit for accounts payable staff who submit invoices but do not build or manage workflows.

Approving invoices: Task Inbox access

Both Human Review nodes (Manager Approval and Director Approval) create tasks in the assigned approver's Task Inbox. Approvers also need the Use role (or Admin, if they also manage the platform). The Financial role is available for users whose primary function is financial oversight: consult your administrator on whether Financial-role users have Task Inbox access in your tenant configuration, since role permissions are editable.

Separation of duties

Assign the User Interaction node to the submitter's user ID or role, and the Human Review nodes to the approver's user ID or role. Do not assign the same user to both the submission task and the approval task for the same invoice instance. DAVE does not enforce this separation automatically: it is a governance decision you implement through User Assignment configuration.

What happens if the Agent Interaction node cannot parse the invoice data?

Configure the agent's prompt to write a structured error field to the workflow payload when parsing fails. Add a second output port to the Routing node (or insert an additional Routing node after the Agent Interaction node) to check for this error field and route to an End node labeled "Parsing Failed" or back to the User Interaction node for resubmission. Without this path, a failed parse may result in the Routing node's amount field being empty, which the default catch-all port handles.

Can I add a Safety node to this workflow?

Yes. Insert a Safety node (teal / Shield icon) between the Agent Interaction node and the Routing node. The Safety node screens the extracted invoice data against configured policies before the amount-based routing decision is made. This is useful if your invoices may contain sensitive data that should be flagged before human reviewers see it.

What if the API Call to the payment system fails?

The API Call node captures the response status and maps it to a workflow field. Add a Routing node after the API Call node to check the response status field: route a success status to End: Approved and Submitted, and route an error status to a User Interaction node or End node that alerts the finance team to the submission failure. Without this path, an API failure may leave the instance in an ambiguous state.

Can the same person submit and approve an invoice?

Technically yes, if they are assigned to both tasks and have the Use role. In practice, this defeats the purpose of an approval gate. Assign the User Interaction node to the submitter's user ID or role and the Human Review nodes to a different approver's user ID or role. Separation of duties is a governance requirement you enforce through User Assignment, not a platform-level restriction.

How is the approval decision recorded for audit purposes?

Every Human Review task completion is recorded in the workflow instance record with the reviewer's identity, their decision (Approve, Reject, or Request Changes), an optional comment, and a timestamp. DAVE's full audit logging captures this for every instance. When SOC 2 or GDPR compliance modes are enabled for the tenant, these records support change management and access control audit requirements.

Can I trigger this workflow automatically when an invoice arrives by email or API?

The workflow as described starts with a User Interaction node, which requires a human to submit the invoice manually. To trigger automatically, replace the User Interaction node with an API Call node that fetches the invoice from an external system (email parser, document management system, or ERP), or configure an external system to call DAVE's API to start a workflow instance with the invoice data pre-populated in the payload. The rest of the workflow (validation, routing, approval, submission) runs identically.