Conversation Flow
A Conversation Flow lets you script how the assistant moves through a single conversation — step by step, branching on what the customer says, and calling tools at the exact moments you choose. You build it on a visual canvas, no code required, and the assistant follows the graph during every live call or chat.
Where Workflows fire before and after the conversation, Conversation Flow drives what happens inside it. Use it whenever the assistant must collect specific information, follow a deterministic path, or stay on a question until the customer actually answers.
When to use Conversation Flow
- Structured intake — collect specific fields in a specific order before the assistant goes open-ended.
- Hard branches based on customer answers — route "new patient" down a different path than "follow-up".
- Goal-gated steps — keep the assistant on the current question until the customer has clearly answered it.
- Mixing automated steps into a conversation — call a tool to look up a record, then carry on talking.
If the conversation is purely open-ended ("answer any question about our product"), you don't need a flow. A good system prompt plus a knowledge base is enough.
The two node types
A flow is a graph of two kinds of nodes connected by edges. You drag each from the left palette.
| Node type | What it does |
|---|---|
| Conversation | The assistant takes a turn. It can be an LLM-generated turn (driven by a mini-prompt and any tools or data sources you attach) or a fixed line of text. After the turn, the node can extract named values from what the customer said. |
| Tool function | The assistant silently calls a tool (look up a contact, fetch an order, query Postgres) and stores the result. No customer-facing turn. The flow then advances. |
Each Conversation node can also carry a goal — a one-line description of what counts as "done". The assistant won't leave that node until the goal is met, so it will keep asking until the customer actually gives an answer.
The three edge types
Edges decide which node comes next.
| Edge type | When to use |
|---|---|
| Direct | The default when a node has only one outgoing edge. The flow takes it unconditionally. |
| Variables | The edge fires when a named variable extracted earlier in the flow matches a value (using ==, !=, >=, <=). First matching edge wins. |
| Description | The edge has a free-text description, and the assistant chooses which edge best matches the conversation so far. Used for soft branches like "caller sounds urgent" vs "caller is browsing". |
Four business use cases
Dental clinic — new-patient intake. Bright Smile Dental asks every new caller a fixed sequence: full name, date of birth, insurance provider, reason for visit. Each question is a Conversation node with a goal ("the caller has clearly given their date of birth") and an extraction. If the caller already has a record, a Tool node looks them up and skips the intake. Outcome: 100% of new-patient intakes captured cleanly, no missing fields, and the receptionist spends zero time on data entry.
Fintech onboarding — KYC gating. A neo-bank uses a flow that refuses to open any product-related conversation until a kyc_complete variable is set to yes. The first three Conversation nodes capture ID type, ID number, and address; a Tool node validates against the KYC provider; only then does a Description edge open the rest of the conversation. Outcome: regulator-friendly conversation logs, no leaked information to non-verified callers.
Real estate — buyer vs seller routing. A brokerage's assistant asks once whether the caller is buying, selling, or renting. A Variables edge routes to one of three sub-flows. The buyer sub-flow asks about budget and zip; the seller sub-flow asks for property address; the rental sub-flow takes a phone number for a callback. Each sub-flow ends with a tool call to log the lead in HubSpot.
E-commerce — returns workflow. A meal-kit company runs a flow that asks for the order number first, looks up the order with a Tool node, then branches with Variables edges based on order status: delivered (refund eligible), in-transit (offer redelivery), cancelled (apologise and refund). Outcome: refunds resolved without a human, and the agent transcript shows the exact branch taken — useful for finance reconciliation.
Example node definition
A Conversation node that asks for visit type and extracts the answer:
{
"id": "n_triage",
"type": "conversation",
"data": {
"llm": "gpt-4o-mini",
"response": {
"type": "llm",
"value": "Ask the caller whether this is a new-patient visit or a follow-up."
},
"extractions": [
{ "name": "visit_type", "description": "new or follow_up" }
],
"goal": {
"enabled": true,
"value": "The caller has clearly stated whether they are new or a follow-up."
}
}
}
A Variables edge that routes new patients down the intake path:
{
"source": "n_triage",
"target": "n_new_intake",
"data": {
"type": "variables",
"variables": [
{ "name": "visit_type", "value": "new", "condition": "==" }
]
}
}
Building one in the dashboard
- Open Automation → Conversation Flow → New flow.
- Drag a Conversation node onto the canvas. Click it to set its mini-prompt, extractions, and (optionally) a goal.
- Add the next node (Conversation or Tool function). Drag an edge from the first node and pick the edge type.
- Repeat. End with a Conversation node that delivers the closing message.
- Save. Open the assistant you want to drive with this flow and pick it under Conversation Flow.
The assistant still has its regular system prompt — the flow drives the steps that match, and the system prompt handles anything off-script.
Tips
- One question per Conversation node. It makes goals and extractions easier to write.
- Always set a goal on critical-data nodes. Without it, the flow will move on even if the caller dodged the question.
- Test in the Playground before linking. Walk every branch at least once.
Where to next
- Workflows — automate what happens before and after the conversation.
- Forms library — for structured data capture without building a full flow.
- Playground — test the flow end to end before going live.