Branches, Loops, Parallel Paths and Failures

The Decide group holds the steps that shape the path of a run rather than its data. Four of them are containers: they hold other steps inside a lane on the canvas. Drag a card over a lane to move it in; a step inside a container reads item as the container's current item.

Branch#

Which way does it go? A branch has arms, each with a condition (when), and a fallback. By default the first arm whose condition is true runs; with match all, every true arm runs. If none is true, the fallback runs. The branch's output names the arms that ran and what each gave.

Build a condition as rows (Status · is · Paid) or as an expression (item.amount > 1000 and item.category = "Transfer").

Loop#

For each item in the list runs the lane once per item. While runs it while a condition holds, and until or stop when end it early — the way to page through results or retry until done. A while or until loop has a maximum number of iterations so it cannot run away. What each iteration gives (its yield) is what the loop hands on.

Parallel#

Do these at the same time. Each arm is a lane of its own. The step joins when all of them, any one or at least n have finished; what happens to arms still going when the join is decided is the step's own setting. Steps in one arm cannot read steps in another, so put what both need before the parallel step.

Try#

Try this, and catch a failure. The lane runs; if a step in it fails, the first catch lane whose error types match handles it (with error holding the failure), and finally runs either way. Use it for a failure you expect — a page that is sometimes missing, a destination that is sometimes busy — without failing the run. A Stop with an error inside a try is caught like any other failure.

When a step fails#

Every step has an If it fails tab with its own policy:

• Retry. How many attempts, the backoff between them (none, constant, linear or exponential, with the first delay and the longest delay) and jitter (none or full), optionally only for some error types.
• When it still fails: Fail the run, Continue with nothing from this step, or Route the failure to the step's error port so a later step can deal with it.
• Deadlines. A timeout for the step (or the whole scope, on a container), and a heartbeat a long step must keep up.

A retry never repeats something that already happened: a step that writes records what it wrote, and a retry sends only what is missing.

Wait#

Pauses the run for a duration, until a time, or for an event with a timeout — a reply on a conversation, a message reaching a mailbox. A waiting run is marked waiting in the runs panel and holds nothing in memory while it waits.

Approval#

Ask someone to approve. The run pauses until the number of people you ask have approved, or one rejects, or the time you set runs out (which counts as rejected). The decision is bound to exactly the items the step is holding, so what was approved is what goes on. Put it before anything that cannot be undone. See Approvals and grants.

Stop with an error#

Ends the scope with a failure you name (What went wrong?, shown in the run's history, and a failure name a Try can tell apart). Use it to refuse input that should never go on. Outside a Try it fails the run.

Calling another automation#

Run another automation starts one with the input you give it and, with Wait for it to finish?, waits for its answer. You choose the version that is on or an exact version. If this run stops first, the called run is stopped too or left to carry on, as you choose.

The called automation must list this one among the automations that may call it, and runs under its own grant. A chain of calls stops at three deep; an automation never calls itself. A failed run can start an error automation the same way, handed the run and its error.

Respond to the webhook#

For an automation started On a webhook, this step answers the request with a status code, a kind of answer (JSON or plain text) and a body. See Webhooks.

Stopping a run from outside#

The automation's settings can also end a run on your behalf: a time limit after which the run fails, is cancelled or is flagged, and events that cancel it when they arrive. A run that is cancelled, or fails, undoes what it can: a step that can be undone is undone, newest first, and the run ends compensated.