Forms Builder
The Forms Builder is a canvas editor for structured, multi-screen forms. Instead of asking one question per chat message, you lay out fields on a canvas, group them into screens, and connect them into a flow. The same form definition serves two surfaces: on WhatsApp it is published as a native WhatsApp Flow (Meta's full-screen form experience inside the chat), and on the web it renders as a multi-screen form in the customer portal. You build once; the platform generates the right output for each channel from the same nodes and edges.
Forms are not standalone — they are triggered from a Bot Builder conversation through the Form List node, which sends the form at the right moment and maps the submitted fields back into flow variables for conditions, messages, and API calls downstream.
How a Form Becomes a WhatsApp Flow and a Web Form
The builder stores the form as a graph of nodes and edges. A backend screen builder resolves that graph — sanitizing IDs, resolving connections, grouping page sequences, marking terminal nodes — and generates WhatsApp Flow JSON (screens plus a routing model). The exact same builder runs with a web flag to produce the payload the customer portal renders, so both channels stay consistent by construction.
A few things differ per surface:
| Behavior | Web (customer portal) | |
|---|---|---|
| Rendering | Native WhatsApp Flow screens | Multi-screen form in the portal |
| Text formatting | Rich text only outside forms; plain text inside form screens | Markdown in titles, labels, descriptions, and option texts |
| Field validation | Native Flow validation (required, input types) | Renderer-side validation: required, email, number, min/max selected |
| Opt-In labels | One single label | Optional per-state labels (checked / unchecked) |
Pages: Grouping Fields into One Screen
By default, each node becomes its own screen. To show several fields together — filled in and submitted as one unit — wrap them between a Page Start and a Page End node:
- Page Start opens the screen and carries its presentation: title, inner title, description, and an optional header image.
- Every input node connected between them renders on the same screen.
- Page End closes the screen and defines the submit button text; it can also mark the page as terminal (the end of the form).
Everything between Page Start and Page End becomes one screen with a single submit action. Nodes outside any page each get their own screen.
Node Categories
The node palette groups nodes into three categories:
| Category | Nodes | Purpose |
|---|---|---|
| Structure | Start, Page Start, Page End | Entry point and screen grouping |
| Messages | Message, Send Image, Interactive Options | Display content or branch the flow |
| Data Collection | Text Input, Email, Phone, Date, Location, File, Password, Opt-In, Checkbox Group, Radio Buttons | Collect data into form variables |
See the node reference for every node and its configuration fields.
Variables
Each input node saves its answer to a variable you pick in the node's Save to Variable section. The system appends a type suffix to the variable name based on the node type — a Text Input bound to customer produces customer_response, an Email node produces customer_email, and so on. The full suffix table is in the node reference. When the form runs from a Bot Builder flow, the Form List node maps these form variables back to flow variables.
Things to Know
One form, two channels. Web-only capabilities (such as Opt-In per-state labels) are attached only when building the web payload, so the published WhatsApp Flow always stays valid.
Screens submit as the customer advances. Each screen carries its collected variables forward, and terminal screens return the full set of collected values.
File uploads are heavier. File screens require a server round-trip (data exchange) before the flow advances, unlike plain inputs where navigation is immediate.