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

# Edges & Logic

> Connect nodes and add conditional branching.

Edges are the wires between workflow nodes. Each edge carries the output of its source node into the input of its target. Edges can be unconditional (always traverse), conditional (traverse only if a predicate matches), an explicit **else** path, or a loop body edge.

## Unconditional edges

The default. After the source node finishes, control flows along its outgoing edge. Use multiple outgoing edges for fan-out: one trigger, several downstream actions.

## Conditional edges (if / else)

A conditional edge has a **condition** that is checked against the data collected so far in the run. A condition is a group of rules combined with **and** / **or**, where each rule compares a value against another using one of the supported operators: equals, does not equal, greater than, less than, and contains. Both sides of a rule can reference values from the trigger by wrapping them in double curly braces (`{{ }}`).

The first edge whose condition matches is taken; the rest are skipped. The optional **else** edge takes whatever didn't match.

The else edge can't be removed while any conditional edges still exist on the same node. When you add the first conditional edge to a node, Custral automatically ensures an else path exists.

## Loop edges

The **Loop** action steps through a list and runs its **loop body** edge once per item. Inside the body you can reference the current item, its position in the list, and the total count. The body runs to its end marker before the next item begins. Each loop is configured with an error behavior (**stop**, **warn**, or **ignore**) that decides what happens if processing one item fails.

## Cycle detection

You can't add an edge that would create a loop back to an earlier node. Workflows always flow forward. Long-running iteration belongs in a [Sequence](/automation/sequences/overview) with a wait step, not a workflow loop.

## How a run executes

* When the triggering event happens, the matching workflow runs immediately and its actions run in order. If any action fails, the run is marked **failed** and stops there.
* Each step in a run can read the trigger data plus the output of every step that ran before it.
* Because the whole chain runs at once, steps that involve a long wait belong in a [Sequence](/automation/sequences/overview) step with an explicit wait rather than inline in a workflow.

## See also

* [Triggers](/automation/workflows/triggers)
* [Actions](/automation/workflows/actions)


## Related topics

- [Workflows](/automation/workflows/overview.md)
- [Workflow Actions](/automation/workflows/actions.md)
- [Jobs](/automation/jobs/overview.md)
- [Troubleshooting](/automation/workflows/troubleshooting.md)
- [Automations](/automation/overview.md)