Quick answer: WhatsApp Flows are Meta's framework for structured, multi-screen forms rendered natively inside a WhatsApp conversation — appointment booking, lead qualification, order lookup, surveys — completed without a browser redirect. In Orbit the lifecycle is: build the flow in the visual editor at Messages → WhatsApp → Flows (or start from one of five templates, or from a plain-language prompt with the AI generator), run it end-to-end against the sandbox test panel, publish it to Meta from the same surface, then send it from the campaign builder or the inbox composer. The customer's structured submission lands back in the conversation thread and on the contact record as parsed fields, not as an opaque webhook payload.
This post is the operator guide for that lifecycle. The WhatsApp Business API explainer covers the channel itself and the flow-builder vs journey-builder post defines the vocabulary split; here the concern is one thing: how a flow goes from an idea to a working in-thread form, and what to check when a stage misbehaves.
Why flows exist at all
The pre-Flows pattern for collecting structured data over WhatsApp was a redirect: send the customer a link, they open a web form in the browser, submit it, and the two systems (messaging and form tooling) reconcile later. That works, but it costs conversion at every boundary — the redirect, the page load, the context switch — and it costs the operator a data-reconciliation problem on every submission.
Flows remove the redirect. The form is rendered by the WhatsApp client itself using a JSON definition you publish to Meta; the customer completes it inside the thread; the submission returns through the same webhook channel as any inbound message. Notice what that means for an operator's mental model: a flow is closer to a message template with interactive screens than to a web form. It has a Meta-side lifecycle (draft → published → deprecated), Meta-side validation at upload, and a call-to-action that rides on a template or freeform message.
The lifecycle in Orbit, stage by stage
Each stage has one home surface and one failure mode worth knowing.
- Build. The visual editor turns flows into a node canvas: every screen is a node, navigation between screens is a drag-and-drop edge, and the component palette covers the full Meta v6.3+ component set — text inputs, dropdowns, date pickers, checkboxes, chip selectors, opt-in toggles, rich text, image headers, embedded links, and navigation lists — organised in five categories (Input, Display, Navigation, Consent, Terminal). Selecting a component opens a config drawer for labels, validation rules, and the submission action. If you would rather not start from a blank canvas, the template picker ships five production-ready starting points (Appointment Booking, Lead Capture, Customer Survey, Contact Us, Order Tracking); if you would rather start from intent, the AI Flow generator takes a plain-language prompt and a category and produces a complete definition with a review step before you commit. A raw JSON view is available as a toggle for direct editing or pasting from Meta's documentation.
- Test. Before a flow ever reaches Meta, the test panel runs it end-to-end against a sandbox WABA: validation errors, broken navigation paths, and dead-end screens surface here rather than in front of customers. This is the stage to be strictest with — a flow that fails Meta's upload validation costs a round trip, and a flow whose navigation strands a customer mid-form costs more.
- Publish. Orbit submits the flow definition to Meta directly from the builder, generating Flow JSON at the current version (v7.x — new screens get the newer components like image headers automatically). Meta's own model validation runs at upload; since mid-2026 the Orbit pipeline pre-checks the definition against that model so first-upload rejections (historically the most common Flow operations failure) are caught client-side before submission. Once Meta accepts, the flow is published and usable from any surface that can send it.
- Send. Published flows are sendable from three places. In the campaign builder, a flow is a first-class message type — one message thread carries the whole form, no redirect. In the inbox composer, a Flow picker button sits next to the template picker and sends the published flow through the same delivery pipeline as templates, with the call-to-action, first screen, and navigation action filled in. Via the API, flows attach as the interactive payload on a WhatsApp send. The picker hides itself when an organisation has no published flows, so it only appears when there is something to send.
- Handle responses. A flow submission comes back as a normal inbound WhatsApp message whose payload Orbit parses into structured fields. In the conversation thread the response renders as a readable summary; on the contact record the answers map to fields agents and downstream automations can act on — so a booking flow's selected slot or a lead form's stated budget is a queryable value, not a blob in a transcript.
The operating checklist for production flows
These are the properties that separate a demo flow from one you can run volume behind:
- Keep every screen reachable, and every path terminating. Meta's validation rejects some dead configurations at upload, but the sandbox test panel is cheaper still — run every path, not just the happy one, before publishing.
- Version consciously. Existing flows stay at the Flow JSON version they were created under; new flows default to the newest (v7.1-era components, including image headers). When you need a newer component in an older flow, re-import the exported JSON as a new flow rather than mutating in place.
- Export what you run. Flows export and import as JSON, so version control is a one-click habit — keep the exported definition beside each published flow so a recall, audit, or re-import into another WABA connection is a file operation, not a reconstruction.
- Treat consent components as consent. The Consent category (opt-in toggles) exists because flows often collect marketing-adjacent data; what the toggle captures is proof state the contact record carries forward, the same posture as the consent-proof-first explainer argues for SMS and email.
- Watch Meta recategorization and rating, not just delivery. A flow rides on the same quality signals as templates; keep an eye on the wave-level shifts described in the WhatsApp quality-rating post, because a flow send that the account can't sustain looks identical at the composer until it fails.
Frequently asked questions
Do I need to write Flow JSON to use WhatsApp Flows in Orbit?
No. The visual editor builds screens and navigation without touching JSON, and a raw JSON view is available for operators who prefer direct editing or want to paste from Meta's documentation. Both paths produce the same definition that Orbit submits to Meta.
Can I test a flow before customers see it?
Yes. The builder's test panel executes the flow end-to-end against a sandbox WABA before publishing, catching validation errors and broken navigation paths. Publishing to Meta only happens after you choose to submit.
Where do customers' flow answers end up?
Submissions return as inbound WhatsApp messages that Orbit parses into structured fields: the answers render in the conversation thread and land on the contact record, where agents and downstream automations can act on them as queryable values.
Can I move a flow between WhatsApp Business numbers?
Yes. Flows export as JSON from Orbit and re-import into any WABA connection, so moving between Meta accounts or backing up a production flow is a file operation.
What happens when Meta's Flow JSON spec moves to a new version?
Existing flows remain at the version they were published under and keep working. New flows created after an update generate JSON at the newest version, picking up newer components automatically.
Resources
- The changelog hub — search "WhatsApp Flows" for the visual editor, AI generator, and inbox composer entries
- WhatsApp Business API explainer
- RCS vs WhatsApp decision guide