What are WhatsApp Flows? Native in-chat forms explained

Updated 2026-09-19 · 5 min read · By the Convo360 team

The definition

A WhatsApp Flow is Meta's own name for a structured, multi-step form that appears as a native full-screen experience inside WhatsApp itself. The customer never leaves the chat or opens a browser tab. This is different from a regular chatbot "flow" (the general term for an automated conversation), which is why the naming can be confusing: a WhatsApp Flow is one specific, Meta-defined interactive message type you can send from within a conversation flow.

Where a link to an external booking page risks losing the customer at the moment they are asked to leave WhatsApp, a native Flow keeps the entire interaction, including the questions, choices and confirmation, inside the same app they are already using.

Screens and components

A Flow is built from one or more screens, each containing components such as:

• Text and headings (instructions, context)
• Text input (name, address, order number)
• Dropdown and radio button lists (pick one option)
• Checkboxes (pick multiple)
• Date and time pickers (booking a slot)
• An image or a final confirmation footer

Screens can branch: for example, choosing "New patient" on screen one can show a different set of fields on screen two than choosing "Returning patient" would.

A well-designed Flow rarely needs more than two or three screens. Cramming every possible field onto one screen defeats the purpose of a guided, step-by-step form, while splitting a simple enquiry across five screens adds friction of its own. The right length usually mirrors how many distinct decisions the customer is actually making.

Static vs dynamic (endpoint-based) Flows

A static Flow works entirely with fixed content: the options shown do not change based on real-time data, which is enough for a simple enquiry or feedback form.

A dynamic Flow is connected to your own server (an endpoint). As the customer moves between screens, WhatsApp calls that endpoint to fetch live information, such as which appointment slots are actually still free today — before showing the next screen. This is more powerful but needs a working backend to answer those requests reliably.

Most businesses start with a static Flow for their first launch: a feedback form, a lead-intake questionnaire, an event RSVP — since it needs no backend work at all, and move to a dynamic Flow only once a specific use case genuinely needs live data, such as a clinic showing only the doctor's actually-free appointment slots rather than a fixed list that might already be booked out.

Why this matters for an Indian business

Sending a link out of WhatsApp to an external form measurably loses people at that exact step. Some customers simply will not tap a link from an unfamiliar business, and mobile data or a slow page load adds friction that a native form avoids entirely. A Flow keeps the whole booking, enquiry or feedback process inside the one app most Indian customers already trust and already have open.

It also looks and feels more official than a plain button-and-text conversation, which matters for use cases like appointment booking, loan enquiry eligibility checks, or event registration where a customer is sharing real personal details.

It also reduces a specific kind of support burden: a customer who abandons an external form midway rarely tells you why, while a native Flow's structured, screen-by-screen design makes it far less likely someone gets confused about what to fill in next or gives up because a page failed to load on a slow mobile connection.

Common misunderstandings

• Confusing it with a regular chatbot flow: your automated conversation logic is a "flow"; a WhatsApp Flow specifically is Meta's native form message type used inside that conversation.
• Assuming every Flow needs a server: only dynamic, endpoint-based Flows do; a static feedback or intake form does not.
• Skipping Meta's review process: like templates, most Flows need approval before they can be sent, and rushed launches without testing the review turnaround can delay a campaign.
• Forgetting the 24-hour window still applies: sending a Flow outside an open customer-service window generally still needs a Flow attached to an approved template.
• Overloading one screen with too many fields: a Flow crammed onto a single long screen loses much of its advantage over a plain message; splitting logically related fields across two or three screens usually completes better.

How it shows up in Convo360

Convo360's Flow Builder includes a WhatsApp Flow (native form) block alongside Buttons, List Menu and Carousel. Drop it into any conversation flow, design the screens, and publish it through WhatsApp Studio for Meta's review like a template. When the customer submits it, their answers land back in the conversation as variables, savable to a CRM lead, sent to a Google Sheet, or used to branch the rest of the flow with a Condition step. See the official Meta WhatsApp Flows documentation for the latest component list and review requirements. Because the block sits inside the same visual builder as every other step, a Flow can be combined with a preceding AI Reply or Buttons step to first understand what the customer needs, and only present the full form once it is clear which one applies.

Example conversation

Frequently asked questions

Related reading

Available across India — see WhatsApp & AI calling automation by state and city.