Flows, paths, and the designer

A trigger decides which events enter the flow. Each path then checks its own condition and runs its actions in order. A path without conditions runs for every admitted event.

Paths are independent: if two paths match, both run. Their left-to-right order does not make one an “else” branch. To send exactly one notification, make the conditions mutually exclusive.

Select the trigger, a path, or an action to edit it in the inspector. Add actions from the picker. Move actions up or down to change execution order, and move paths left or right to organize the canvas.

Each action can read the event and outputs from earlier actions on its own path. It cannot read an action below it or on another path. Moving or removing actions of the same type can change their output references; check downstream templates afterward.

Use trigger filters to narrow all activity entering the flow. Use path conditions when different subsets need different actions. Path conditions must all match.

For example, the trigger can select USDC transfers of at least 100000 tokens. An unconditional path emails your team; a second path with Value ≥ 1000000 also posts to Slack. The larger transfer runs both paths.

New flows start Disabled. Enable after configuring and testing the flow and obtaining a matching example. Active means the flow is enabled; it does not guarantee a recent event has matched.

Disable a flow to pause future matching. Re-enabling starts from current activity rather than replaying the time it was disabled. Error means the flow needs attention, such as a broken filter or disconnected connection.

A temporary action failure may leave the flow Active. A configuration problem can stop the flow immediately, and repeated failed runs can also move it to Error. Open Runs to read the reason, fix the action or connection, test, and re-enable the flow.

By default, an action failure stops the remaining actions on that path; those later actions are marked Skipped. Other matching paths are evaluated independently.

Turn on Continue on error only when later actions can work without the failed result. An action that expects the missing output may otherwise send an incomplete message.