> For the complete documentation index, see [llms.txt](https://docs.hablla.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hablla.com/hablla-docs-en/automation-flows/all-components/whatsapp-components/whatsapp-question.md).

# WhatsApp Question

### Overview

The **WhatsApp Question Component** is an action node focused on data collection, screening, and building structured dialogues. Its main function is to send a question directly to the customer and wait for a real-time response. The automation flow enters a waiting state (*standby*) in this component until the user responds with valid data, allowing the provided response to be stored and the automation tree to branch according to the choice or content typed.

### Configuration Parameters

The component parameters define the question display structure and data storage rules:

* **Type:** Determines the interaction mechanism of the sent question:
  * `Text`: Sends a simple text message and waits for a response typed manually by the customer.<br>
  * `Interactive`: Sends native button or interactive list formats from the WhatsApp API.<br>
* \_*Message (* Required Field):\_\* The content or wording of the question that will be shown to the customer.<br>
* **Has Variable (Toggle Switch Key):** When enabled, it allows storing the response. It can operate in *Fixed* (platform static variable) or *Expression* (dynamic expression).<br>
* \_*Variable (* Required if active):\_\* Defines the name of the internal container (e.g.: `response`) that will receive the response value.<br>
* **Response Target:** Allows mapping and saving the received data directly into native or custom contact fields, such as `Name`, `Email`, `Address`, `NPS`, `CSAT` or a `custom_field` (custom field).<br>
* **Ignore if goal is met (Toggle Switch Key):** If the contact already has the target field filled in previously in their profile, the component automatically skips the question and moves on to the next node without bothering the user.<br>
* **Accept response:** Data validation filter that establishes what is a valid response. For questions of the *Text*, it restricts input to formats such as: `Text`, `Number`, `Phone number`, `Email`, `Location` or `Audio`. If the user sends something outside the format (e.g.: sending an image when an email is expected), the system rejects it and repeats the question.<br>

### Visual Builder

The builder interface adapts and expands dynamically according to the properties selected in the field *Type*:

#### Configuration for the Type `Interactive`

When switching the type to interactive, the component displays the field **Response Type** to define the button layout:

* **Button Option (Quick Replies):** Allows building quick-click buttons that appear below the message. The interface limits creation to **at most 3 buttons**.<br>
* **List Option (List Messages):** Turns the interaction into a clean options menu. When this mode is selected, the visual form expands and requires the following mandatory fields:
  * `Button to open list *`: The text that will appear on the main click button (e.g.: "Select").<br>
  * `Section Title *`: The header of the window that groups the items.<br>
  * `List`: Repeater block where the administrator uses the button **+ Add item** to include the nominal choice options (*Button*) and support texts (*Description*). The interface limits creation to **at most 10 list items**.<br>
* **Multiple Outputs:** Toggle key that, if enabled, creates a physical output port in the graphical editor for each button or list item created, allowing fully custom paths to be drawn for each user response.<br>

### Special Operators

The logical properties of this component handle data type validation (*data validation*) and input state management:

* **Regex Validator and Native Types:** When configured to accept only `Email` or `Phone number`, the component runs a syntactic validation script on the customer's response. If validation fails, the engine blocks the flow from advancing and repeats the question message.<br>
* **Interactive Metadata Mapping:** In questions of the `Interactive` structured as a list, the field *Accept response* changes its default scope to the `Valid Data`. The system checks whether the clicked text exactly matches one of the structured IDs in the builder list, ignoring random texts typed by the user during that menu step.<br>

### Practical Examples

The table below shows classic application scenarios for this component to guide intelligent interactions via WhatsApp:

| **Selected Type**         | **Builder Configuration**                                                                                                                   | **Response Target / Variable**                                                                                            | **Practical Use Case**                                                                                                                          |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| `Text`                    | <p><strong>Message:</strong> "What is your email?"<br><br><br><br><strong>Accept response:</strong> <code>Email</code></p>                  | <p><strong>Target:</strong> <code>Email</code><br><br><br><br><strong>Variable:</strong> <code>customer\_email</code></p> | Capture and validate the customer's email. If they type something without `@`, the system repeats the question until it receives a valid email. |
| `Interactive` *(Buttons)* | <p><strong>Message:</strong> "Are you already a customer?"<br><br><br><br><strong>Buttons:</strong> \[Yes], \[No]</p>                       | <p><strong>Variable:</strong> <code>is\_customer</code><br><br><br><br><strong>Multiple Outputs:</strong> Enabled</p>     | Create a quick initial screening menu with 2 buttons, branching the flow into different paths based on the user's click.                        |
| `Interactive` *(List)*    | <p><strong>Message:</strong> "Choose a service option"<br><br><br><br><strong>Items (Max 10):</strong> \[Support], \[Sales], \[Finance]</p> | <p><strong>Target:</strong> <code>custom\_field</code><br><br><br><br><strong>Multiple Outputs:</strong> Enabled</p>      | Present a robust options menu in list format (Options Menu) to direct the customer to the company's correct departments.                        |


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.hablla.com/hablla-docs-en/automation-flows/all-components/whatsapp-components/whatsapp-question.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.