> For the complete documentation index, see [llms.txt](https://flapjax.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://flapjax.gitbook.io/docs/automations/actions.md). # Actions {% hint style="info" %} Tip: For details on how to add and configure actions in the flow builder, see the [Flow Builder guide](/docs/automations/flow-builder.md). {% endhint %} Records Filtering Communication People Delays Utility\ \ Parsing Flow Control *** ### Variables Insert values from the trigger, or from any earlier action, anywhere in your automation. Variables use the `{{variable.name}}` syntax and work in most text fields. Click the **{ }** button in any supported field, or type `{{`, to browse what is available. Flapjax organises variables by source, meaning the trigger, a specific action or loop data, and filters them by data type so you see compatible options alone. *** **Example.** An email subject reading `Welcome, {{person.first_name}}!` becomes *"Welcome, Alex!"* for a person named Alex. Flapjax resolves variables per recipient at send time. *** ### Fallback Values Some variables can come back empty, say for a person with no first name or email address. Set a fallback value and Flapjax uses that instead. A missing variable otherwise resolves to an **empty string**, so `Welcome, {{person.first_name}}!` reads *"Welcome, !"* for someone with no first name. Give `person.first_name` a fallback of `there` and they get *"Welcome, there!"*. You set fallback values per variable, and per language on multi-language content. For how the same variables drive language-specific delivery, see [Multi-language, worked end to end](/docs/automations/actions/communication.md#multi-language-worked-end-to-end). *** ### Variable colours: reading a chip at a glance Every inserted variable renders as a chip, and its colour tells you the state before you run the automation. | Color | Meaning | What to do | | ------------- | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | 🟠 **Orange** | Valid variable, **no fallback** set | Fine on a field that always has a value. On one that can be empty, such as `first_name`, add a fallback so recipients avoid a blank. | | 🔵 **Blue** | Valid variable **with a fallback** | Nothing. This is the safe state for any field that can be empty. | | 🟣 **Purple** | A **system token**, such as *now*, *yesterday* or *generate UUID* | Nothing. System tokens always produce a value, so they need no fallback. | | 🔴 **Red** | **Invalid variable**, with a broken reference or a type that no longer matches the field | Fix or remove it. A red variable blocks activation. | **Why a variable turns red.** Nearly always, the variable pointed at something that later changed. An email subject uses `{{person.favorite_color}}`, then someone **deletes the `favorite_color` attribute** in Settings. The variable now points at a field that no longer exists, so the chip turns red. Two other causes look the same. Someone removed the earlier action that produced the value, which takes the variable's source away. Or a field's type changed, which leaves the value incompatible with where it sits. **Adding or removing a fallback.** Click the variable chip to open its popover. Enter a value in the **Fallback** field to add one, and the chip turns blue. Clear the field to remove it, and the chip returns to orange. Fallbacks belong to each individual variable. The same `{{person.first_name}}` in two fields can carry a different fallback in each, and per-language content keeps a separate fallback per language variant.