Node Reference¶
Every step in your WhatsApp conversation flow is represented by a node. This section documents every node type available in the Menu Designer.
Node Comparison Table¶
| Icon | Node | Category | Purpose | Status | Terminal? |
|---|---|---|---|---|---|
| π | Entry Point | Start | Marks where the conversation begins | Live | No |
| π¬ | Message | Messaging | Sends a text message | Live | No |
| π | Menu | Messaging | Presents options the customer can choose | Live | No |
| π₯ | Question | Messaging | Asks for input and saves the answer | Live | No |
| π | Condition | Logic | Branches the flow based on a variable | Preview | No |
| π€ | AI Chat | AI | Answers questions using the Knowledge Base | Live | No |
| π | Document | Media | Sends a file attachment (PDF, etc.) | Live | No |
| πΌοΈ | Image | Media | Sends an image | Live | No |
| π€ | Human Handoff | Actions | Transfers to a live agent | Live | Yes |
| βοΈ | Send Email | Actions | Sends an email notification | Live | No |
| β‘ | API Action | Actions | Calls an external API | Preview | No |
Preview nodes
Preview nodes (Condition, API Action, Lead Form) can be placed and configured in the designer and pass publish validation, but the live assistant does not execute them yet β a customer reaching one sees a polite "not yet supported" message instead of the node's behaviour. Keep them out of published flows until they go Live.
Terminal Nodes
Terminal nodes end the conversation β they have no outgoing connections. Currently, Human Handoff is the only terminal node. All other nodes should be connected to a next step.
Edge Types¶
Connections between nodes come in three types:
| Edge Type | Used By | Description |
|---|---|---|
| Continue | Most nodes | A simple "go to the next step" connection |
| Menu Option | Menu node | Routes to a specific node based on which option the customer taps |
| Condition Branch | Condition node | Routes to "Yes" or "No" based on a variable check |
See Connection Rules for the full matrix of which nodes can connect to which.
Variable System¶
Several nodes work with variables β named values that store customer input during a conversation:
- Question captures input into a variable (e.g.,
{{name}},{{email}}) - Condition reads a variable to decide which branch to follow (Preview)
- API Action can store API response data in a variable (Preview)
- Message, Send Email, Menu, Document and Image captions can use
{{variable_name}}in their text to insert saved values
An undefined variable renders as an empty string β customers never see a raw {{...}} token. Built-in variables ({{customerName}}, {{customerPhone}}, {{tenantName}}, {{timestamp}}, {{conversationId}}) are always available β see the Question node for details.
Variable Scopes¶
| Scope | Lifespan | Use Case |
|---|---|---|
| Conversation | Resets each time a new conversation starts | Temporary data like menu selections |
| Contact (planned) | Persists across all conversations with this contact | Customer name, email, preferences |
Contact scope is not active yet
The runtime currently stores all variables per conversation, regardless of the scope selected in the designer.
Coming Soon¶
The following node types are planned for future releases:
| Node | Description |
|---|---|
| π Lead Form | Collects several fields (name, email, phoneβ¦) in one node β a multi-field version of Question. Visible in the designer palette today as a Preview node. |
| π Webhook | Receive incoming webhook events |
| βοΈ Variable | Set or transform variables without customer interaction |
| π Switch | Multi-way branching (more than two paths) |