> 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/data-transformation/if.md).

# IF

### 1. Overview

The **IF Conditional Component** is the platform's main logic control and flow-branching node. Its primary function is to evaluate one or more validation rules based on JavaScript or internal CRM data in real time. When processing the contact, the automation engine tests the provided instruction and splits the journey path in a binary way: if the validation result is positive, the corresponding output is activated to **True** (*True*); otherwise, the contact is routed through the output of **False** (*False*).

### 2. Configuration Parameters

The parameterization of this node is centralized in a single block of interpretive coding:

* **Expression:** Structured open text field for receiving formulas, logical operators, or short codes wrapped by double-brace syntax `{{ ... }}`. This is where the administrator specifies the logical criteria to be tested (such as comparing the value of a collected variable with fixed text or validating a system constant).<br>

### 3. Visual Builder

The builder interface prioritizes operational simplicity to act as a purely logical decision-making node in the visual map:

* **Direct Input Panel:** Displays a clean layout focused exclusively on filling in the field *Expression*. Since it does not send messages and does not interact externally with channels, the visual builder does not require connection selectors, media, or target variables.<br>
* **Physical Graphic Branching:** In the flow design editor, this component visually changes the structure of the automation paths by providing two fixed physical output ports on its right side, commonly labeled as:
  * Green / Upper Output: **True** (*True* / condition success).<br>
  * Red / Lower Output: **False** (*False* / condition failure).<br>

### 4. Special Operators

The component's processing properties manage advanced syntax validation and logical variable checking:

* **JavaScript Interpreter and Safe Navigation (`?.`):** As exemplified in `image_3be49d.png`, the field accepts properties such as `{{$data?.phone == "5561999999999" || $data?.phone == "5561992222222"}}`. The use of the safe navigation operator (`?.`) ensures that the flow does not break or freeze if the evaluated property (in this case, the phone number) is empty at the time of the check.<br>
* **Equivalent Logical Operators:** The expression interpreter supports conventional comparison and logic operators:
  * `==` or `===` (Equal to).<br>
  * `!=` (Different from).<br>
  * `||` (OR logical operator - passes if at least one of the conditions is true).<br>
  * `&&` (AND logical operator - requires all listed conditions to be true).<br>
* **Instant Execution in Microseconds:** The rules engine computes the result fully synchronously in the server memory. There is no waiting state (*standby*) in this block; the contact enters the component, its expression is calculated, and it is routed to the next step instantly.<br>

### 5. Practical Examples

The table below demonstrates classic scenarios of how to fill in the expression field to achieve efficient segmentations within the service flow:

| **Expression Configured in the Builder** | **Type of Operation Performed**              | **Internal Engine Behavior**                                                                                                 | **Practical Use Case**                                                                                        |                                                                                                                        |
| ---------------------------------------- | -------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| \`{{$data?.phone == "5561999999999" \\   | $data?.phone == "5561992222222"}}\`          | Exception list validation (OR).                                                                                              | Checks whether the contact's phone number is exactly number A or number B. If so, it goes to the True output. | Isolate internal test numbers from management or approval testers so they receive a different flow from end customers. |
| `{{response == "Yes"}}`                  | Simple direct string comparison.             | Evaluates whether the variable `response` (coming from a previous question block) is identical to the typed or clicked text. | Direct the user to the hiring branch if they have clicked the "Yes" button in an interactive menu.            |                                                                                                                        |
| `{{nota_nps >= 9}}`                      | Mathematical relational operator validation. | Checks whether the number stored in the score variable is greater than or equal to 9.                                        | Filter promoters in a satisfaction survey to direct the flow to a request for a public review on Google.      |                                                                                                                        |


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

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

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.