Conditions, loops and parallel branches

Conditions, loops and parallel branches are engine steps that hold other steps inside them. You describe the logic in plain English, such as "if the contact already exists, update it, otherwise create it", and Claude or the assistant builds the structure. None of these steps counts a task; the actions inside them do.

Conditions

A condition step runs its then steps when a test is true and its else steps when it is false. The test is an expression written without {{ }} braces:

{
  "step_id": "contact_exists",
  "type": "condition",
  "name": "Contact already exists?",
  "if": "len(steps.find_contact.output.records) > 0",
  "then": [ { "step_id": "update_contact", "type": "assembly" } ],
  "else": [ { "step_id": "create_contact", "type": "assembly" } ]
}

A condition has exactly two branches. There is no switch step; for more than two outcomes, put a condition inside the else branch of another.

Writing the test

Field names with spaces use brackets, as in mappings: trigger['Field Name']. Wrapping the whole test in {{ }} is tolerated.

These values count as false: empty text, 0, false, an empty list, an empty object, and a missing value. Everything else counts as true.

When the data is missing

Apps often leave a field out of a response instead of returning it empty. A condition treats a missing field the same way as an empty one for equality and length:

Test for "nothing came back" explicitly with len(...) == 0 when the automation should behave differently in that case.

What a condition outputs

A condition's output field branch is then, else, or none. none means the test was false and the condition has no else branch. To check which way a condition went, test branch == "then", since branch == "else" misses the none case.

Loops

A for-each step runs its do steps once for every item in a list. items is an expression that must produce a list:

{
  "step_id": "each_line_item",
  "type": "for_each",
  "name": "Create a line for each order item",
  "items": "trigger.body.line_items",
  "max_iterations": 500,
  "do": [
    {
      "step_id": "create_line",
      "type": "assembly",
      "settings": {
        "SKU": "{{ loop.item.sku }}",
        "Quantity": "{{ loop.item.qty }}",
        "Line Number": "{{ loop.index + 1 }}"
      }
    }
  ]
}

Inside the loop body:

Iterations run one after another, in list order. If items is not a list, the step fails.

Limits and stopping early

• max_iterations caps the number of passes. Leaving it out means no cap.
• A break loop step inside the body stops the loop. No further items are processed, and the output from the pass that broke is kept.

What a loop outputs

Check truncated when a list can exceed the cap. The run still succeeds when items are dropped, so the dropped items are otherwise invisible.

To collect values across passes for use after the loop, use the Variables app: Append to array inside the loop, Get after it.

Parallel branches

A parallel step runs several branches of steps at the same time:

Each branch starts from the data available before the parallel step. A step in one branch cannot read a step in another branch; a later step after the parallel step can read any branch that completed. Steps that pause the run, such as Snooze or waiting for child automations, are refused inside a parallel branch.

Groups

A group draws a labelled box around a run of steps on the diagram, and can be collapsed. It has no effect on how the steps run: the grouped steps execute in place as if the group were not there.

The diagram shows each condition's branches and each loop's body steps nested under the step that holds them.

Stopping a record

The Flow Control app has two actions that stop the current record without running its remaining steps:

For a polling trigger that returned several records, processing continues with the next record. The remaining steps are skipped at every nesting level, and error handlers do not run for a success halt.

There is no step that stops every record in a run at once.

Running automations one at a time

The Flow Control action Serialize automation execution makes runs that share a group name wait for each other. A run holds the group from that step until the run ends. A run that parks, for example on a snooze, releases the group and takes it again when it resumes.

• Place the step first in the automation so the whole run is covered.
• The scope is My account (default) or Linked accounts.
• A run waits up to 30 minutes for the group. If the wait runs out, the step fails.
• A run holds the group for at most 60 minutes; a longer run loses the guarantee for its remainder.

Troubleshooting

Next steps

• Field mapping
• Error handling and retries
• Fan-out and fan-in
• Testing an automation