Workflow Reference
Workflows are directed acyclic graphs (DAGs) that define how data flows through triggers, AI reasoning, conditional logic, and actions. Each workflow is a visual canvas of connected nodes that execute in dependency order.
Node Types
Trigger Nodes
Every workflow starts with a trigger node. The trigger defines what event starts the workflow and what data is available to downstream nodes.
| Trigger Type | Source | Data Available |
|---|---|---|
chat |
Chat widget message | trigger.message, trigger.visitor, trigger.history |
email |
Inbound email | trigger.from, trigger.subject, trigger.body, trigger.thread |
webhook |
GitHub, Jira, custom | trigger.payload, trigger.headers |
schedule |
Cron expression | trigger.scheduledAt, trigger.frequency |
database |
CRM data change | trigger.record, trigger.changeType, trigger.source |
manual |
Dashboard button | trigger.input (user-provided) |
AI Nodes
AI nodes send data to a language model and return the response. They support two execution modes:
Standard mode — the node sends a prompt and receives a single response:
System: You are a lead scoring agent...
User:
→ Response: { "score": 85, "reason": "Enterprise company, active evaluation" }
Tool use mode — the node can call tools (actions) during reasoning. The AI decides which tools to call, processes the results, and continues reasoning:
System: You are a customer support agent. Use the available tools to help the visitor.
User:
→ Tool call: crm_lookup_contact({ email: "[email protected]" })
→ Tool result: { name: "Jane Smith", plan: "enterprise", ... }
→ Response: "Hi Jane! I can see you're on the Enterprise plan..."
AI Node Configuration
| Field | Description |
|---|---|
model |
AI model to use (claude-haiku, claude-sonnet) |
provider |
Model provider (anthropic) |
systemPrompt |
Instructions defining the agent's role and behaviour |
temperature |
Creativity level (0.0 = deterministic, 1.0 = creative) |
maxTokens |
Maximum response length |
outputFormat |
Expected output format (text, json) |
Conditional Nodes
Conditional nodes route the workflow down different paths based on field values.
| Operator | Description | Example |
|---|---|---|
equals |
Exact match | category equals "support" |
contains |
Substring match | message contains "pricing" |
greater_than |
Numeric comparison | score greater_than 80 |
in |
Value in list | category in ["sales", "presales"] |
matches |
Regex match | email matches "@enterprise\\.com$" |
exists |
Field is present | visitor.company exists |
Each condition maps to a target handle (output port). If no condition matches, the defaultHandle is used.
AI Output + Conditionals
When branching on AI output, instruct the AI node to return structured JSON with a known field (e.g. "category": "support"). Conditional nodes work best with predictable, structured values rather than free-text.
HITL Nodes
HITL (human-in-the-loop) nodes pause workflow execution until a human takes action.
| Field | Description |
|---|---|
mode |
Review type: review |
blocking |
If true, workflow pauses until human acts. If false, continues and corrections are retroactive. |
When a HITL node activates, the pending item appears in the HITL Review page with the full conversation context and the agent's draft response.
Action Nodes
Action nodes perform operations on external systems:
| Action | Description |
|---|---|
email.send_email |
Send an email via connected integration |
email.reply_email |
Reply to an email thread |
hubspot.update_contact |
Update a HubSpot contact record |
hubspot.create_deal |
Create a new HubSpot deal |
github.create_issue |
Create a GitHub issue |
github.comment_issue |
Comment on a GitHub issue |
github.create_pull_request |
Open a pull request |
chat.send_response |
Send a response to the chat widget |
workflow.execute |
Trigger another workflow (sub-workflow) |
Action configuration uses data.app + data.action + data.config:
{
"data": {
"label": "Send Follow-up",
"app": "email",
"action": "send_email",
"config": {
"to": "",
"subject": "Thanks for chatting with us",
"body": ""
}
}
}
Code Nodes
Code nodes run isolated container sessions for custom logic. They can read input data, execute arbitrary code, and return structured results.
| Field | Description |
|---|---|
image |
Container image to use |
timeout |
Maximum execution time in milliseconds |
Input data is mounted at /tmp/io/input/ and results are written to /tmp/io/output/result.json.
Execution Order
Nodes execute in topological order based on their connections. A node only runs after all of its upstream dependencies have completed.
Skipped Branches
When a conditional node's condition is not met, the entire downstream branch is skipped. Skipped status propagates through all nodes that depend exclusively on the skipped branch.
Exception: If a node has multiple incoming connections and at least one non-skipped parent has executed, the node will run. This handles convergence points where multiple branches merge.
Template Variables
Any node can reference the output of an earlier node using template variables:
| Syntax | Description |
|---|---|
| `` | Data from the trigger node |
| `` | Text output of a named node |
| `` | JSON field from a named node |
| `` | Workflow-level settings |
Template variables are resolved at execution time. If a referenced node was skipped, the variable resolves to an empty string.
Workflow Run History
Every workflow execution is logged with:
- Start time and duration
- Node-by-node results — input, output, and status for each node
- Routing decisions — which conditional branches were taken and why
- Tool calls — which tools the AI called and their results
- Errors — stack traces and error messages for failed nodes
- Skipped nodes — which nodes were skipped and which branch caused the skip
View run history by clicking on a workflow and selecting the Runs tab.
