WhatsApp Flows: Forms Inside Chat and How to Use Them With AI

WhatsApp Flows: Forms Inside Chat and How to Use Them With AI

WhatsApp Flows is a feature of Meta's WhatsApp Business Platform that opens screens with structured fields (option lists, dates, checkboxes, text inputs) inside the conversation itself, so the customer can fill in a form without leaving the app. What comes back to the company is data organized by field, not loose text. Flows do not replace an AI agent. They handle predictable data collection, while the agent handles the conversation and the cases that fall outside the script.

Key takeaways

• Flows are native WhatsApp forms: the customer fills in screens with defined fields, and the company receives the answers in structured form.
• They suit data the company needs complete and in the right format, such as appointment booking, sign-up, quote requests or satisfaction surveys.
• An AI agent is better at understanding open requests, answering questions and deciding the next step. A Flow is better at collecting closed fields.
• The two work best together: the agent leads the conversation and, when it is time to collect data, offers the form.
• Like any collection of personal data, it requires a clear purpose, a minimum number of fields and attention to LGPD (Brazil's data protection law).

What are WhatsApp Flows?

Anyone who has tried to collect data by message knows the problem. You ask for a name, an address, a preferred date and a type of service, and the customer answers half of it in a voice note, the other half in two messages, with the date written three different ways. Someone at the company has to reorganize everything.

Flows solve this by replacing the message exchange with an interface. The company sends a message with a button, the customer taps it, and a screen opens inside WhatsApp with fields the company designed. There can be a single screen or several in sequence. At the end, the answers arrive as a set of data, and the company decides what to do with them.

As Meta's documentation describes it, the feature is part of the WhatsApp Business Platform (the API), not the regular WhatsApp Business app. Companies that already use the API for customer service, or plan to, are on the right track. Availability, component types and limits change over time, so check Meta's official Flows documentation before starting any project.

How a Flow works in practice

Without getting into implementation details, the life cycle of a Flow has only a few parts.

• Design: the company defines the screens and fields. This can be done in the building tools Meta offers or by describing the flow in a structured format.
• Sending: the flow reaches the customer through a message with a button. Inside the customer service window, it can be a regular message. Outside it, the rules for outbound messages apply, and sending usually depends on an approved template and on consent (see WhatsApp outbound messages: templates and opt-in).
• Filling in: the customer opens the screens, chooses and types, and the flow itself can validate what is required.
• Return: when the customer finishes, the answers reach the company's system through the same event channel that receives the other API messages.
• Dynamic screens (optional): when a screen needs current information, such as open time slots, the flow can query a company service. This makes the form more powerful and also raises the technical responsibility.

The practical point is that a Flow decides nothing. It collects and delivers. Whoever reads the result and acts on it (creating a CRM record, booking a slot, opening a ticket) is the company's system or the agent.

Where Flows complement an AI agent

It is common to treat the two as competitors: either the customer chats freely with the AI, or fills in a form. In practice, each covers a weakness of the other.

An AI agent handles open language well. It understands that the customer wants to "move my Thursday appointment" without picking a menu option. But when it needs ten exact fields, free conversation turns into an interrogation, and the model may accept an ambiguous answer, forget a field or misread a date.

A Flow handles structure well. It guarantees that the date field is a date, that the option is one of the allowed ones, and that nothing required is left blank. But it does not understand context: if the customer has a question midway, the form does not answer it.

The healthiest split usually looks like this:

• The agent receives the request in natural language, clarifies doubts and identifies the intent.
• When the intent requires closed data, the agent triggers the Flow instead of asking field by field.
• On receiving the answers, the agent (or a deterministic workflow) confirms with the customer, performs the permitted action and records what it did.
• If something unexpected happens, the agent resumes the conversation or hands off to a person.

This logic follows a principle Anthropic describes in its "Building effective agents" guidance: use the simplest solution that works, and reserve the model's autonomy for where judgment is needed. Collecting a date field does not need judgment. Interpreting a confusing complaint does.

For anyone building the conversation layer, it is also worth reading the guide on how to integrate AI into your company's WhatsApp, which covers the foundation a Flow fits into.

Flow or free conversation: a decision guide

A simple checklist to decide, field by field or process by process:

• Is the data always the same, in a known format (date, option, number, email)? Use a Flow.
• Does the answer depend on interpreting what the customer means, with details that vary from case to case? Use a conversation with the agent.
• Does a typing or interpretation mistake carry a real cost (wrong appointment, wrong address, payment data)? Prefer a Flow, with a confirmation at the end.
• Is the customer likely to have questions while filling it in? Put the agent before the Flow to clarify, and offer the form afterward.
• Is the process short, with two or three data points? Conversation is often enough. A form just to ask for a name may be overkill.
• Is the customer already tired, upset or in a sensitive case? Avoid the form and route to a person.
• Is your audience unfamiliar with smartphones? Test the Flow with real users before making it the only path, and keep a conversational alternative.

When in doubt, start with the simplest option and measure. Free conversation can become a Flow once the fields stabilize, and that is easier than going the other way.

Illustrative scenario: a service visit request

Imagine, as an illustrative scenario, an equipment maintenance company that takes service visit requests over WhatsApp. This is not a real case, just an example to show how the roles divide.

The customer writes: "My equipment stopped working and I need someone this week." The AI agent reads the message, confirms the request is for a technical visit and asks whether the customer is already registered. Instead of asking one by one for company name, address, equipment type, defect description and time windows, the agent sends the visit request Flow.

The form has one screen to identify the equipment (option list), another to describe the defect (free text field, with a length limit) and another to choose the time window (options drawn from the schedule). When the customer finishes, the answers come back structured.

The system validates what can be validated by rule, without AI: the equipment exists in the register, the time slot is still free. The agent then summarizes the request for the customer, asks for confirmation and creates the ticket. If the free-text defect description mentions something out of the ordinary, such as a safety risk, the agent does not decide alone: it hands off to a technician with the summary ready.

Notice what each part did. The Flow guaranteed complete data. The deterministic rules guaranteed consistency. The agent handled the conversation and the routing. Nobody competed with anybody.

LGPD, security and quality precautions

A form inside WhatsApp looks harmless, but it collects personal data, and that brings obligations. Some precautions that apply to any data collection:

• Purpose and minimum necessary: every field needs a reason. If nobody uses the information, do not ask for it. The ANPD, Brazil's data protection authority, is the official reference for guidance on data protection in Brazil.
• Transparency: tell the customer, in simple terms, what the data will be used for. If consent is involved, record when and how it was given.
• Sensitive data: avoid asking for health data, biometrics or documents through a Flow without a clear legal basis and a legal review.
• Free text is untrusted input: what the customer types in an open field may reach an AI model. Treat it as data, never as instruction, and consult OWASP's guidance on prompt injection prevention.
• Server-side validation: do not rely only on the screen's validation. Check what arrived in the company's system before performing any action.
• Action limits: what the agent can do with the data received should be defined in advance. For that, see guardrails for AI agents.
• Logging: keep a record of what was sent, what was received and what decision was made, so you can audit and correct.

If the flow makes decisions that significantly affect the customer, also consider the right to review provided by LGPD, the subject of the article on automated decisions and Article 20.

How to apply the method: map, limit, pilot and hand off

For a company that wants to test the feature without launching a large project, the sequence below works well. It follows the working method we use for any AI automation.

• Map: choose a process where the team currently reorganizes messy incoming data. Note the fields that are actually used and how often the team has to go back to the customer to complete information. This is the baseline for comparing later.
• Limit: define the minimum fields, who can see the answers and which actions the agent may perform with them. Anything involving payment, sensitive data or a decision with real impact stays out of the first pilot or goes under human approval.
• Pilot: put a single real flow live, logging every send, answer and action. Agree beforehand on a simple success metric, such as the share of requests that arrive complete without rework. The article on lead qualification on WhatsApp without turning it into a form helps in thinking about the balance between conversation and collection.
• Hand off: make sure the customer can leave the form and talk to a person at any moment, and that the person receives the context already collected. At the end of the pilot, the team decides to expand, adjust or stop based on the record, not on impressions.

This order avoids the most common mistake: designing a long form before knowing which data matters.

Frequently asked questions

Do WhatsApp Flows work in the regular WhatsApp Business app?

In general, the feature is offered by the WhatsApp Business Platform, the API, and not by the regular app. Because availability rules change, confirm in Meta's documentation and with the API provider your company uses before planning the project.

Do I need an AI agent to use Flows?

No. A Flow can work on its own, triggered by a button or a menu, and deliver the data to a system with fixed rules. The AI agent comes in when there is open conversation before or after the form, to understand requests, answer questions and route cases that fall outside the standard.

Does a Flow replace the form on my website?

It can, in cases where the customer is already in the conversation and filling in a website form would break the flow. But the website form remains useful for people who arrive through other paths. The safest approach is to treat both as entry points to the same record, with the same validation rules.

Which LGPD precautions matter most when using Flows?

Ask only for the data you need, explain the purpose to the customer, limit who can access the answers, and record what was collected and why. Avoid sensitive data without a defined legal basis and, if in doubt, take the case to a legal review before putting the flow live.

Sources

• Meta: documentação do WhatsApp Flows
• Anthropic: Building effective agents
• OWASP: prompt injection prevention
• ANPD: Autoridade Nacional de Proteção de Dados