# Flows, nodes, and connections

A flow is the connected set of steps that defines an automation. The canvas shows where a run starts, which decisions it makes, and where it can finish.

> Automations is in Early access. Your workspace permissions determine which actions you can perform.

## The parts of a flow

| Term         | Meaning                                                                     |
| ------------ | --------------------------------------------------------------------------- |
| Trigger      | The event or schedule that starts a run. A flow has one trigger.            |
| Node or step | One task, such as sending an email, checking a condition, or waiting.       |
| Output path  | A possible result of a step, such as success, failure, matched, or timeout. |
| Connection   | The route from an output path to the next step.                             |
| Run          | One execution of a published flow with its own starting data and history.   |

For example, a reminder flow can follow this sequence:

```text
Appointment event → Delay until reminder time → Send SMS → Wait for delivery
                                                           ├─ Matched → Finish
                                                           └─ Timeout → Notify team
```

Connections control which step runs next. A field mapping separately selects the data a step reads. Connecting **Get contact** to **Send email** does not fill the email recipient automatically.

## One path at a time

A run follows one active path. A **Branch** checks conditions in order and takes the first matching path. Its **Otherwise** path applies when no condition matches.

Paths can reconnect at a shared step. The shared step can read data produced before the split and on the path the run took. A step on an untaken path has no output for that run.

The current builder does not execute loops, parallel branches, or an automatic action for each audience member. A connection back to an earlier step creates a cycle and blocks publication. A list of contacts remains data until a supported action uses it.

## How a run finishes

A successful step can finish the run when its chosen output has no next step. An unconnected action failure fails the run. Connecting a failure path lets you decide how to handle that failure.

Use **Exit** when you want an explicit successful or failed ending, an outcome reason, or a returned result. For example, `no_matching_contact` explains a successful run that deliberately sent no message. An exit ends the run and has no outgoing connection.

A successful run means the flow completed its configured path. Check the channel's message status or add a delivery wait when you need evidence of delivery.

## Drafts and published versions

The draft is your editable flow. Saving it preserves your work without changing the version used by live runs.

Publishing creates a version for new runs. A run keeps the version it started with, including when it waits across a later publication. Editing the draft cannot change an already running workflow.

## Next steps

- [Build and edit a flow](/docs/guides/automations/editor).
- [Use data from earlier steps](/docs/guides/automations/data).
- [Publish and manage automations](/docs/guides/automations/publishing).
- [Browse the Automations guides](/docs/guides/automations).

## Related resources

- [Preview your first automation](/docs/get-started/automations) (docs)
