> ## Documentation Index
> Fetch the complete documentation index at: https://fliqr.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Flow Builder concepts

> Understand how Fliqr AI Flows work — deterministic paths, contact context, personalization, omnichannel messages, and draft vs published versions.

This page explains the mental model behind Flow Builder. Read it once, then build faster with fewer redesigns.

## Deterministic paths

A Flow is a directed graph. Each block does one thing, then continues along a connected output. The same inputs produce the same outputs. That makes Flows ideal for:

* Compliance-sensitive scripts
* Menus and FAQs with fixed answers
* Qualification, booking, and checkout steps
* Any process where every branch is known

When input does not match a branch, design an explicit fallback (condition else-path, Default Reply, or handoff). Do not assume the contact will type a perfect keyword.

## Contact context

Every run is tied to a [Contact](/docs/core-concepts/contacts). As the Flow executes, it can:

* Read system fields (`first_name`, `phone`, `channel`, …)
* Read and write **custom user fields**
* Apply or remove **tags**
* Move cards in a [Pipeline](/docs/core-concepts/pipelines)

Data written mid-Flow is available to later blocks in the same run and to future Flows, Agents, and broadcasts.

## Personalization

Insert contact data in messages with double curly braces:

```text theme={null}
Hi {{first_name}}, your order {{order_id}} is ready.
```

If a field is empty, the placeholder may render blank — set defaults on the field or guard with a **Condition** before sending.

## Omnichannel vs channel-specific

Prefer **Omnichannel** message types when the same content should run on multiple channels. Use channel-specific blocks only when you need a capability that does not translate (for example, WhatsApp interactive lists or Messenger cards).

Test each target channel. Media formats and button limits differ — see [Messages and media](/docs/core-concepts/flows/messages-and-media) and [Limits](/docs/core-concepts/flows/limits).

## Draft vs published

| State         | Who sees it                                                    |
| ------------- | -------------------------------------------------------------- |
| **Draft**     | You, while editing. Not used by live triggers until published. |
| **Published** | Live triggers, broadcasts, inbox **Send Flow**, and API sends. |

Saving edits does not publish them. Always publish after a verified test.

<Warning>
  Publishing swaps the live graph for contacts already inside the Flow. Plan breaking changes with a duplicate Flow and staged cutover.
</Warning>

## Modular design

Keep Flows small and purposeful. Use **Go to Flow** to chain a parent orchestrator into specialized child Flows (payment, FAQ, human handoff). This stays under the [250 blocks per Flow](/docs/core-concepts/flows/limits) limit and keeps ownership clear.

## Escape hatches

| Situation                         | Pattern                                       |
| --------------------------------- | --------------------------------------------- |
| Contact says something unexpected | Default Reply rule → recovery Flow or Agent   |
| Need open-ended help mid-script   | **AI Action** or hand off to an AI Agent      |
| Need a human                      | Assign / notify admin, or transfer in inbox   |
| Need external system data         | **External Request** → map into custom fields |

## Next

<CardGroup cols={2}>
  <Card title="Builder" icon="diagram-project" href="/docs/core-concepts/flows/builder">
    Learn the canvas controls.
  </Card>

  <Card title="Collect data" icon="database" href="/docs/core-concepts/flows/collect-data">
    Capture answers into custom fields and tags.
  </Card>
</CardGroup>