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

# The flow builder

The builder is where a flow is assembled: a canvas of nodes on the left, a configuration panel for whichever node you've selected, and the validation you have to satisfy before the flow can go live.

## Placing steps

Start with a trigger. A flow has exactly one, and it's the node everything else hangs off. Search the trigger catalog, pick one, and configure it if it takes options (the [custom field](/custom-field-changed) and [usage event](/usage-event-tracked) triggers can watch one specific subject or any of them).

Then add conditions and actions and connect them. A condition node has **two outgoing handles**, Yes and No; the edge you draw from each decides what happens on that branch. Nodes with nothing connected to them are never reached, and the builder treats that as an error rather than letting it ship.

**Changing the trigger** removes the current trigger node and every connection it had. The builder asks first, because a new trigger can't inherit edges that assumed the old one's variables.

## Validation

Saving and activating are both gated on the same checks, so a flow can't be activated in a state that couldn't run:

* a trigger node exists, and at least one side-effect action exists (Wait alone does not count),
* no node is left disconnected,
* a **Send email** step has a valid selected email, and one addressed to specific people has at least one recipient,
* a **Populate custom field** step names a field that still exists,
* a **Wait** step has a complete timing within 1 minute to 30 days (including until-event timeouts and optional business hours / exit event),
* no two **Wait** steps can run at the same time (fanned out from the trigger or from the same step; Waits on the Yes and No branches of one condition are fine), and every Wait leads to a step,
* a condition has its segment (or its variable, comparison and value), that segment or variable still exists, the variable is one **this trigger provides**, and the condition leads somewhere on at least one branch.

The last one is the reason validation and execution share the same resolution code: validating a graph differently from how it runs is how an impossible condition gets activated.

## Deleted references

Segments, emails and custom fields can be deleted after a flow references them. The builder doesn't silently drop the step. It marks it (*deleted segment*, *this custom field no longer exists*) and blocks activation until you pick another one.

## Saving versus running

The flow that runs is the **saved** flow. Testing is disabled while you have unsaved changes, for the same reason: a trace of the canvas in front of you would tell you nothing about what production will do.

To rework an active flow without changing what runs, click **More actions** and choose **Duplicate**. The copy starts inactive and takes what is on the canvas, unsaved changes included, and the original stays as it was last saved.

A **Send email** step stores a snapshot of the email's subject, preview text and HTML when you save the flow, and again every time the email itself is saved. That snapshot is what sends. See [Send email](/send-email).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.