Branches and loops

The «Loop» step repeats the steps inside it while a condition is true, up to a maximum number of laps that you set (a new loop starts at 100; the highest you can enter is 500).

• Before each lap the engine checks the limit, and then the condition. A loop with a maximum of N laps therefore succeeds only if the condition turns false after at most N-1 laps of the body. If the condition would only turn false after N laps, the step fails with "the loop exceeded the N laps allowed".
• That failure ends the run as failed, with no automatic retry, unless the loop is inside a Try. Pressing Retry runs it again, which hits the same limit.
• The loop does not have an item variable. The condition sees what the body produced in earlier laps; later laps overwrite same-named values, and the last value stays after the loop ends.
• A wait inside the body parks the whole run; when it resumes, earlier laps are replayed from the record.
• Each lap uses at least one of the 1000 steps a run may take, for the condition alone. A loop of 500 laps with three steps in its body would need 2000, so the run limit usually stops a loop before its own limit.
• The loop step itself costs no credit; the steps in its body cost one per lap.

An Iterate step resolves a collection once, then runs its body once for each item. Inside the body, the item is a variable (the step's own value). The collection is read once and recorded, so a resumed run goes through the same items even if the data changed.

• An empty collection is not an error: the body is skipped.
• A collection of more than 500 items is rejected before the first one is processed: the run fails with "resolved more than 500 elements", and is not retried. It never processes only the first 500. Narrow the source (a filter, a date range) before iterating.
• A search that returns a page of results gives you only that page.
• Variables created in the body accumulate across items, and the last item's value stays.
• Every step in the body counts towards the 1000 steps of the run, and costs credits for every item.

The email and Slack iterators are described in Integrations.

The «Jump to an earlier step» step sends the run back to an earlier step, for retry-style flows ("check again"). It has no condition of its own: put it inside a «Condition» to jump conditionally.

• The target must be a step before the jump: an earlier step at the same level or any level above it, or a step that contains the jump. A step inside the branches of an earlier composite is not a valid target. Saving rejects a target that does not exist or is not earlier.
• You set the maximum number of jumps (default 3, between 1 and 500). When they are used up, the run is not failed: it simply continues with the next step.
• Each jump uses one of the 1000 steps of the run and costs no credit itself. The steps between the target and the jump run again on every pass; each one counts towards the 1000 steps and costs its own credit.
• Variables made on the way are kept; the last pass wins.

The «Try» step is not a repeat but belongs with the other steps that hold a body. It has no fields: it runs the steps inside it, and if one fails the run goes on with the step after the Try instead of ending. Its outcome («Has failed» and «Error message») is what the next steps can read. A Try around a loop or an Iterate step catches the loop limit as a step failure, but not the 500-item limit of Iterate, which ends the run. In the run viewer, the step that failed inside shows as «Caught error». The details, the pattern and what it does not catch are in Errors and retries.

There is no maximum number of steps and no maximum nesting declared for a workflow. The one structural limit is that the stored definition cannot be more than 100 levels deep, counting every wrapper (each nested step adds a couple of levels).

All hard limits, with what happens at each, are in Limits and credits.