Example Workflow: Customer Onboarding

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 onboarding coordinator's Task Inbox. The coordinator submits the new customer record: company name, primary contact, email, account type (for example: Starter, Team, or Business), contract value, and any special requirements. The workflow resumes when the coordinator submits their input. Suggested label: "Submit Customer Record". In the Properties Panel, set User Assignment to the onboarding coordinator or the role responsible for new account intake. Set Notifications to alert them when the task is created.
3. Agent Interaction (purple / Bot icon)
   Invokes an AI agent automatically to validate and enrich the submitted customer record. The agent checks for completeness (all required fields present), normalizes formatting, identifies the account tier from the account type field, and writes a structured enriched record and a normalized account_tier field to the workflow payload. No human involvement at this step. Suggested label: "Validate and Enrich Record". In the Properties Panel, assign the agent configured for customer data validation and select the appropriate model.
4. Routing (purple / GitFork icon)
   A logic-only node that reads the account_tier field written by the Agent Interaction node and routes execution to the correct tier-specific setup path. No agent is invoked and no task is created. Suggested label: "Route by Account Tier". Configure output ports in the Routing Configuration section of the Properties Panel:
   • Port: tier_starterrule: account_tier equals "starter". Priority 1.
   • Port: tier_teamrule: account_tier equals "team". Priority 2.
   • Port: tier_businessrule: account_tier equals "business". Priority 3.
   • Port: defaultno rule, catch-all for unrecognized or missing tier values. Priority 4. Connect to an End node labeled "Tier Unknown" so no instance is left hanging.
5. Agent Interaction (x3, one per tier) (purple / Bot icon)
   Each tier path runs its own Agent Interaction node to perform tier-specific setup tasks. The agent for each tier generates the appropriate provisioning instructions, configuration checklist, and personalized onboarding plan based on the enriched customer record. Each node writes its output to the workflow payload for use in the next step.
   • Suggested label for tier_starter path: "Generate Starter Onboarding Plan"
   • Suggested label for tier_team path: "Generate Team Onboarding Plan"
   • Suggested label for tier_business path: "Generate Business Onboarding Plan"
   All three nodes connect to the same Human Review node downstream (Step 6). You do not need three separate Human Review nodes: the three tier paths converge on a single review step.
6. Human Review (amber / Eye icon)
   Creates a review task in the assigned onboarding manager's Task Inbox. The manager reviews the generated onboarding plan and customer record in the task payload and chooses one of three decisions: Approve, Reject, or Request Changes. Each decision routes execution to a different outgoing path (see Outgoing Paths below). Suggested label: "Onboarding Manager Approval". In the Properties Panel, set User Assignment to the onboarding manager or the role responsible for final sign-off. Set Notifications to Custom audience with the task assignee and instance owner selected, so the manager is notified when the plan is ready and the coordinator knows when a decision has been made.
7. Agent Interaction (purple / Bot icon)
   Reached only after the onboarding manager approves the plan. Invokes an AI agent to generate a personalized welcome message and onboarding email for the new customer, using the approved onboarding plan and enriched customer record from the workflow payload as context. The agent writes the welcome message to the payload. No human involvement at this step. Suggested label: "Generate Welcome Message".
8. API Call (cyan / Zap icon)
   Calls your CRM or customer success platform to create the customer record, attach the onboarding plan, and mark the onboarding workflow as complete. Configure the API Configuration section in the Properties Panel with the Method (POST or PUT), the URL of your CRM endpoint, any required headers (Authorization, Content-Type), and a body template that maps the customer fields and onboarding plan from the workflow payload into the request. Map the response status back into a workflow field for downstream reference. Suggested label: "Update CRM".
9. End: Onboarding Complete (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 onboarding outcome. Suggested label: "Onboarding Complete".
10. End: Rejected (red / Square icon)
    Terminal node for the Reject path from the Human Review node. The onboarding is declined at the manager review step. Suggested label: "Rejected". Optionally insert a User Interaction node before this End node to notify the coordinator of the rejection and collect the manager's reason for the record.

The Request Changes path from the Human Review node loops back to the Agent Interaction node at Step 5 (the tier-specific plan generator for the relevant tier), so the agent regenerates the onboarding plan using the manager's comment as revision guidance. The revised plan re-enters the Human Review node. This loop continues until the manager approves or rejects.

From the Routing node (Route by Account Tier)

From the Human Review node (Onboarding Manager Approval)

All three tier-specific Agent Interaction nodes (Steps 5a, 5b, 5c) connect to the same Human Review node. On the canvas, three incoming edges arrive at the Human Review node's target handle (top circle). This is valid: any node can receive edges from multiple upstream nodes. The Human Review node executes when execution arrives from any of the three paths.

Check all paths using the Fit View button before saving to confirm no port is left dangling.

This workflow uses a branch-then-converge pattern: the Routing node fans execution out to three tier-specific paths, and those paths converge back onto a single Human Review node before continuing. Understanding why this pattern is correct helps you adapt it confidently.

Why branch at all

Different account tiers require different onboarding plans. A Starter customer needs a lightweight self-serve setup guide. A Business customer needs a detailed enterprise configuration checklist, integration guidance, and a dedicated success plan. Running the same agent with the same prompt for both tiers produces a mediocre result for both. Branching lets each tier run an agent configured specifically for its requirements.

Why converge on a single Human Review node

The manager's review task is the same regardless of tier: review the plan, approve or reject. Using a single Human Review node for all three tiers keeps the approval logic in one place. If the reviewer assignment changes (a new onboarding manager joins), you update one node, not three. If the notification configuration changes, you update one node.

Why converge on a single API Call node

The CRM update is identical regardless of tier: create the customer record and attach the onboarding plan. A single API Call node is easier to maintain. If the CRM endpoint changes, you update one node.

Adding more tiers

To add a fourth tier, add a fourth output port to the Routing node, drag a new Agent Interaction node onto the canvas, connect the port to the new node, and connect the new node's source handle to the existing Human Review node's target handle. The rest of the workflow is unchanged.

Preventing infinite revision loops

The Request Changes path loops back to the tier-specific Agent Interaction node. If the agent never produces a plan the manager accepts, the loop runs indefinitely. To prevent this, insert a Routing node (purple / GitFork icon) between the Human Review node's Request Changes port and the tier-specific Agent Interaction node. Configure it to read a revision count field from the workflow payload and route to an End node labeled "Maximum Revisions Reached" after a defined number of attempts.

Three groups interact with this workflow: builders who design it, coordinators who submit customer records, and managers who approve onboarding plans. 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. If you need to build or modify this workflow but do not have the required role, ask your administrator to assign you the Admin or Curate role.

Submitting customer records: Task Inbox access

The User Interaction node (Submit Customer Record) creates a task in the coordinator's Task Inbox. Coordinators 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. Use is the right fit for onboarding coordinators who submit records but do not build or manage workflows.

Approving onboarding plans: Task Inbox access

The Human Review node (Onboarding Manager Approval) creates a task in the manager's Task Inbox. Managers also need the Use role (or Admin, if they also manage the platform). Assign the manager's user ID or role in the User Assignment section of the Human Review node's Properties Panel.

Separation of duties

Assign the User Interaction node to the coordinator's user ID or role, and the Human Review node to the manager's user ID or role. Do not assign the same user to both the submission task and the approval task for the same customer 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 identify the account tier?

If the agent cannot determine the account tier from the submitted record (for example, the account type field is missing or uses an unrecognized value), it should write a recognizable error value to the account_tier field. The Routing node's default catch-all port handles this case and routes to an End node labeled "Tier Unknown", preventing the instance from hanging. Configure the agent's prompt to always write a value to account_tier, even if that value signals an error.

Can I skip the tier branching and use a single onboarding plan for all customers?

Yes. Remove the Routing node and the three tier-specific Agent Interaction nodes. Replace them with a single Agent Interaction node that generates a generic onboarding plan. Connect the User Interaction node directly to this single Agent Interaction node, then continue to the Human Review node as described. The rest of the workflow is unchanged.

Can I add a Safety node to screen the generated onboarding plan?

Yes. Insert a Safety node (teal / Shield icon) between each tier-specific Agent Interaction node and the Human Review node, or between the converging point and the Human Review node if you prefer a single safety check. The Safety node screens the generated plan for policy violations before the manager sees it.

What does the manager see in the Task Inbox?

The manager sees a task of type human_review labeled "Onboarding Manager Approval" in their Task Inbox. The task detail page shows the Payload section, which contains the workflow data accumulated up to that point: the enriched customer record, the account tier, and the generated onboarding plan. The manager reads the plan, optionally adds a comment, and submits their decision (Approve, Reject, or Request Changes).

How is the approval recorded for compliance purposes?

Every Human Review task completion is recorded in the workflow instance record with the reviewer's identity, their decision, 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 access control and change management audit requirements.

Can this workflow trigger automatically when a new customer signs up?

The workflow as described starts with a User Interaction node, which requires a human to submit the customer record manually. To trigger automatically, replace the User Interaction node with an API Call node that fetches the new customer record from your CRM or sign-up system, or configure your sign-up system to call DAVE's API to start a workflow instance with the customer data pre-populated in the payload. The validation, routing, approval, and CRM update steps run identically either way.