WhatsApp Flows: structured forms inside a conversation, not message ping-pong

Buttons and free text can collect one answer at a time, but not a real multi-field form reliably — parsing free-text replies for a name, a date, and an address is fragile in a way that quietly breaks. Flows is Meta's answer: a defined, versioned UI that renders natively inside the chat and posts back structured data.

Advanced

3 min read

The problem that pushes a product toward Flows

A booking feature built purely on free-text replies and buttons — "reply with your name," then "reply with a date," then "reply with an address" — works until a customer replies with all three in one message, or replies out of order, or a date in a format the parser didn't anticipate. Every one of these is a real conversation a human would parse instantly and a backend has to guess at. Flows sidesteps this entirely by rendering an actual structured UI — text inputs, dropdowns, date pickers, radio buttons — natively inside WhatsApp, and returning the submission as clean, typed JSON instead of a sentence to be interpreted.

The pieces: Flow JSON, screens, and where it attaches

A Flow is authored as a JSON document describing one or more screens, each with typed form components, plus the navigation between them:

{
  "screens": [
    {
      "id": "BOOKING_DETAILS",
      "layout": {
        "children": [
          { "type": "TextInput", "name": "full_name", "label": "Full name", "required": true },
          { "type": "DatePicker", "name": "preferred_date", "label": "Preferred date" },
          { "type": "Footer", "label": "Continue", "on-click-action": { "name": "complete" } }
        ]
      }
    }
  ]
}

That Flow is created and published in WhatsApp Manager (or via the Flows API), gets a Flow ID, and is then attached to an outbound message — either directly as an interactive message, or as a button on a message template — the same way an earlier lesson covered attaching Quick Reply buttons to a template. Tapping the button opens the Flow's UI inline, in the chat, without leaving WhatsApp.

The endpoint a Flow needs when data isn't static

A Flow with fixed content (a simple feedback form) needs no backend involvement beyond receiving the final submission through the normal webhook. A Flow that needs dynamic data mid-conversation — showing only currently available appointment slots on screen two, based on what was picked on screen one — calls a business-owned HTTPS endpoint during the flow itself, not just at the end. That request/response is end-to-end encrypted with keys exchanged during the Flow's own setup, which means this endpoint has real implementation weight: decrypting the request, computing a response, and encrypting it back, all within the latency budget of a UI screen transition the user is actively watching.

Draft, Published, and why editing isn't like editing a template

A Flow has its own lifecycle distinct from message templates: it's built and iterated on as a Draft, then explicitly Published. Once published, its core structure can't be silently edited in place the way a draft can — meaningful structural changes require creating a new version. This mirrors why templates need resubmission for changes rather than in-place edits, but for a different underlying reason: a live Flow already has real in-progress user sessions that would break if its screen structure shifted mid-session.

Where Flows fit next to buttons and lists

Flows aren't a replacement for Quick Reply buttons or list messages — they're for the specific case those can't handle: more than one or two structured fields needed at once. A single yes/no confirmation is still better served by a button; a Flow is worth the extra setup weight specifically when the alternative is a multi-message free-text back-and-forth that's fragile to parse.