Support Triage Workflow: Example Framework

This support triage framework routes an incoming support ticket through four stages:

1. Intake: Collect the ticket from the submitting user via a User Interaction node.
2. Safety screen: Run the ticket content through a Safety node before any agent processes it.
3. Classification: An Agent Interaction node reads the ticket and classifies it by type, urgency, and likely resolution path.
4. Routing: A Routing node branches the instance into one of three paths based on the classification output.

The three resolution paths are:

• Self-serve: The ticket matches a known issue with a documented resolution. An Agent Interaction node drafts a response using the knowledge base context. The response is sent without human review.
• Agent-assisted: The ticket requires a personalised response but not specialist escalation. An Agent Interaction node drafts a response. A Human Review node lets a support agent review and approve the draft before it is sent.
• Escalate: The ticket is complex, sensitive, or high-urgency. The instance routes directly to a Human Review node for a senior support agent to handle manually, with the classification output provided as context.

All three paths terminate at an End node. The workflow uses a second Routing node on the agent-assisted path to handle the Human Review decision (approve or request changes), creating a lightweight revision loop on that path only.

Build the following nodes in the Workflow Editor. Drag each from the Node Palette, drop it on the canvas, rename it in the Properties Panel, and connect edges in the order shown. All edges run from the source handle (bottom) of the upstream node to the target handle (top) of the downstream node.

1. Start

Type: Start (green play icon). Label: "Start". No configuration required. Every workflow requires exactly one Start node.

2. Collect Ticket (User Interaction)

Type: User Interaction (blue user icon). Label: "Collect Ticket". Fields section: Configure fields to capture the ticket subject, the ticket body, and the submitter's contact details. These fields become the instance context for all downstream nodes. User Assignment: Assign to the submitting user or leave open for any authenticated user to submit. Notifications: Use the workspace rule (default) or configure a custom notification if you want the submitter to receive a confirmation email when the ticket is received.

3. Screen Ticket Content (Safety)

Type: Safety (teal shield icon). Label: "Screen Ticket Content". Place this node between Collect Ticket and Classify Ticket. The Safety node runs content safety and compliance checks on the ticket body before any agent processes it, and propagates its guardrails to every downstream agent call. Fields section: Configure to evaluate the ticket body field. Output ports: Configure a pass port (leads to Classify Ticket) and a flagged port (leads to a dedicated End node labeled "Blocked: Policy Violation"). Ensure the flagged path terminates at an End node.

4. Classify Ticket (Agent Interaction)

Type: Agent Interaction (purple bot icon). Label: "Classify Ticket". Agent Assignment: Assign a classification agent. The agent's system prompt should instruct it to read the ticket subject and body, classify the ticket by type (billing, technical, account, general), urgency (low, medium, high, critical), and resolution path (self-serve, agent-assisted, escalate), and write these classifications to named workflow fields: ticketType, urgency, and resolutionPath. Fields section: Configure to read the ticket subject and body fields from Collect Ticket, and to write ticketType, urgency, and resolutionPath.

5. Route by Classification (Routing)

Type: Routing (purple GitFork icon). Label: "Route by Classification". Routing Configuration: Configure three output ports with routing rules based on the resolutionPath field written by Classify Ticket:

• Port "self-serve": resolutionPath equals self-serve, priority 1. Edge leads to Draft Self-Serve Response.
• Port "agent-assisted": resolutionPath equals agent-assisted, priority 2. Edge leads to Draft Agent-Assisted Response.
• Port "escalate": resolutionPath equals escalate, priority 3. Edge leads to Escalation Review.

6a. Draft Self-Serve Response (Agent Interaction)

Type: Agent Interaction (purple bot icon). Label: "Draft Self-Serve Response". Agent Assignment: Assign a response drafting agent. System prompt: read the ticket subject, body, and ticketType; draft a complete self-serve resolution response using the relevant knowledge base context; write the response to draftResponse. Fields section: Read ticketType, ticket subject, ticket body. Write draftResponse. Edge leads to End ("Resolved: Self-Serve").

6b. Draft Agent-Assisted Response (Agent Interaction)

Type: Agent Interaction (purple bot icon). Label: "Draft Agent-Assisted Response". Agent Assignment: Assign the same response drafting agent or a separate one configured for personalised responses. System prompt: read the ticket subject, body, ticketType, and urgency; draft a personalised response; write to draftResponse. Fields section: Read ticketType, urgency, ticket subject, ticket body. Write draftResponse. Edge leads to Review Draft Response.

6c. Escalation Review (Human Review)

Type: Human Review (amber eye icon). Label: "Escalation Review". User Assignment: Assign to senior support agents or the support escalation role. Fields section: Pass the ticket subject, body, ticketType, urgency, and the classification rationale to the reviewer as context. The reviewer handles the ticket manually and approves to close. Edge from the approved port leads to End ("Resolved: Escalated").

7. Review Draft Response (Human Review)

Type: Human Review (amber eye icon). Label: "Review Draft Response". User Assignment: Assign to support agents. Fields section: Pass draftResponse, ticket subject, and ticket body to the reviewer. The reviewer can approve the draft or request changes. Output ports: approved and changes-requested.

8. Route Review Decision (Routing)

Type: Routing (purple GitFork icon). Label: "Route Review Decision". Routing Configuration: Two ports: approved (leads to End "Resolved: Agent-Assisted") and changes-requested (leads back to Draft Agent-Assisted Response, closing a revision loop). Set priorities so approved is evaluated first.

End nodes

Use four distinct End nodes with descriptive labels:

• "Blocked: Policy Violation" (from the Safety node's flagged port)
• "Resolved: Self-Serve" (from Draft Self-Serve Response)
• "Resolved: Agent-Assisted" (from Route Review Decision, approved branch)
• "Resolved: Escalated" (from Escalation Review, approved port)

Distinct End node labels make instance outcomes distinguishable in reporting.

This workflow uses the following named workflow fields. Configure these consistently across all node Fields sections and agent system prompts. Field names are case-sensitive: a mismatch between the name written by one node and the name read by the next is the most common cause of context not flowing correctly.

The instance context accumulates as the instance progresses. A field written by Collect Ticket is still present when Escalation Review runs. You do not need to re-pass fields at each step: they persist in the instance context for the lifetime of the instance.

This workflow creates tasks at three nodes: Collect Ticket (User Interaction), Review Draft Response (Human Review), and Escalation Review (Human Review). Each task appears in the Task Inbox of the assigned user or role when the instance reaches that node.

DAVE ships with six default tenant roles: Admin, Create, Curate, Use, Reporting, and Financial. All roles are editable by your administrator. For this workflow, the relevant role assignments are:

• Collect Ticket: Any user with the Use role can submit a ticket. If the workflow is customer-facing, configure the User Interaction node's User Assignment to allow the appropriate users or leave it open to all authenticated workspace members.
• Review Draft Response: Assign to users with the Use role who are designated support agents. These users review AI-drafted responses and approve or request changes.
• Escalation Review: Assign to senior support agents or a dedicated escalation role. These users handle complex or sensitive tickets manually.

The Admin and Curate roles are required to build and modify the workflow in the Workflow Editor. The Create role is required to build and update the classification and response drafting agents. Support agents who only complete tasks need only the Use role: they do not need editor or agent access.

Notification behavior for each task node is configured in the Notifications section of the Properties Panel. The default (Use workspace rule) follows the workspace-level setting for task.assigned events. For high-volume workflows, consider setting Review Draft Response to "No notification" if the volume of review tasks would otherwise generate excessive email, and instead configure a custom notification for Escalation Review only, since those tasks are higher priority and less frequent.

This framework is a starting point. The following variations are common when adapting it to a specific support operation.

Adding a fourth resolution path

If your support operation has a fourth outcome (for example, a refund or account action that requires a separate approval flow), add a fourth output port to the Route by Classification Routing node and connect it to a new branch. The Routing node supports multiple output ports: add a new port with the appropriate routing rule and priority.

Replacing the urgency field with a numeric priority score

Some teams prefer a numeric priority score (1 to 10) rather than a categorical urgency field. Update the classification agent's system prompt to produce a priorityScore field instead of urgency, and update the routing rules on Route by Classification to use numeric comparisons (greater than, less than) rather than equality checks.

Adding an API Call node for CRM lookup

Insert an API Call node between Collect Ticket and Classify Ticket to fetch the submitter's account history from your CRM before classification runs. Map the relevant account fields (account tier, open tickets, recent purchases) into the instance context. The classification agent can then use account history as additional context when determining the resolution path. See the guide on calling an external API mid-workflow for configuration details.

Removing the revision loop on the agent-assisted path

If your support operation trusts the AI draft enough to send without human revision, remove the Route Review Decision Routing node and connect Review Draft Response's approved port directly to End ("Resolved: Agent-Assisted"). Remove the changes-requested port and its back-edge. This simplifies the graph and reduces the number of nodes by two.

Using Agent Review instead of Human Review for draft quality

Replace Review Draft Response (Human Review) with an Agent Review node. Configure the Agent Review agent to evaluate the draft against quality criteria: tone, completeness, accuracy relative to the ticket, and compliance with your response policy. Route passing drafts to End and failing drafts back to the drafting agent for revision. This removes the human review step from the agent-assisted path entirely, suitable for high-volume workflows where human review of every draft is not practical.

For a workflow with this many branches, Information nodes are essential for maintainability. The Information node (indigo info icon) does not affect execution: it creates no tasks, invokes no agents, and has no effect on the instance. Its only purpose is to add notes directly on the canvas.

Recommended Information node placements for this workflow:

• Beside Route by Classification: Document the three routing rules, the field names they evaluate, and the priority order. Label the node "Routing rules: resolutionPath".
• Beside the revision loop: Document the loop: "Draft Agent-Assisted Response → Review Draft Response → Route Review Decision → (changes-requested) back to Draft. Loop closes on approval." Label the node "Revision loop: agent-assisted path".
• Beside the Safety node: Document the policies enforced and the flagged path destination. Label the node "Safety: screen ticket body before classification".
• Beside the field list: List all seven workflow fields, their sources, and their consumers. This is the most valuable annotation for future editors who need to add a new agent step or debug a context issue.

Place Information nodes beside (not in) the execution path. A node placed in the path and connected with edges would be reached by the instance at runtime. Information nodes should have no incoming or outgoing edges.