Router, Parallel, and Wait

The four helpers control how a Flow runs, rather than doing something themselves. They live in the editor under the Helpers tab.

Helper	Description in the interface
Router	Take different paths
Parallel	Runs the following steps individually for each list element.
Merge runs	Waits for all list runs and then continues the Flow.
Wait	Pauses the Flow for a set duration.

---

Router

The Router branches the Flow: depending on a condition, execution continues down a different path.

Typical uses:

• By amount: over €1000 goes for approval, under that gets confirmed directly
• By category: request goes to the responsible team
• By status: different notifications

Conditions

You set a condition on each outgoing path. Available operators:

Operator
is equal to	is not equal to
is greater than	is less than
is greater than or equal to	is less than or equal to
starts with	ends with
contains
is before	is after
is empty	is not empty
is true	is false

You combine multiple conditions with and or or — in the dialog via the choice All conditions met (AND) or At least one condition (OR). It applies to all rows together.

You pull the values from previous steps — see Data between steps.

The value first, then the condition

Which operators are offered depends on the type of the chosen value. The dialog knows this type from the last test run — without a test run, all operators appear, including ones that don't fit. → Testing Flows

For cases that can't be expressed as rows, the dialog offers Advanced logic: there the condition is written as an expression. → Building conditions

Always provide a default path

If no condition matches, the Flow reaches a dead end at this point. With numbers and select fields, it's easy to only think of the expected cases and forget empty values.

Provide a path with is empty, or word the last condition so that it catches everything else.

Check conditions before going live

A Router with an incorrectly set condition silently sends cases down the wrong branch — there's no error message. Test each branch individually with matching test data. → Testing Flows

---

Parallel

Parallel is the loop: the step takes a list and runs the following steps individually for each element.

There's almost always a step before it that delivers a list:

Trigger
   ↓
Load all entries          →  delivers a list
   ↓
Parallel                  →  once per element
   ↓
Email                      →  runs per entry

Typical uses:

• Mail merge to all entries of a view
• Create a job for each line item of an invoice
• Process the rows of an imported CSV file individually

Without Parallel, it only happens once

The most common mistake when working with lists: using Load all entries and then being surprised that the following email only gets sent once — or with unusable content.

A list isn't a repetition yet. Only Parallel turns it into individual runs.

Watch out with large lists

If Parallel runs over an unfiltered view with thousands of entries, the following steps get executed thousands of times — including emails and calls to outside systems.

Filter the view down to what actually needs processing first, and test with a small set.

---

Merge runs

Waits for all list runs and then continues the Flow.

Parallel opens a section where the following steps run individually per list element. Merge runs closes that section again: the Flow waits until all runs are finished, then continues once, a single time.

Load all entries              →  list
   ↓
Parallel                      →  from here, per element
   ↓
Email                          →  runs per entry
   ↓
Merge runs                     →  waits for all
   ↓
Update entry                   →  runs only once again

The step has no settings — it only marks the end of the parallel section.

What you need it for

Without this step, everything after Parallel stays in repeat mode. As soon as you want to do something once after the loop, you need it:

• send a summary once all the individual emails are out
• set an aggregate status once all line items have been processed
• close out a job once every row of an import has gone through

Nesting is possible

Every Parallel opens a level, every Merge runs closes one. This lets you nest loops inside each other — for example per invoice, over its line items.

Make sure the pairs match up. A missing merge leaves the Flow stuck in repeat mode; an extra one has nothing to close.

---

Wait

Wait pauses the Flow for a set duration and then continues it.

Typical uses:

• Reminder a few days after a sign-up
• Follow-up when no response arrives within a deadline
• Spacing between two calls to an outside system

Wait is not scheduling

Wait measures from the moment the step is reached — not up to a fixed date. "Three days after the trigger" works well with it; "every Monday at 9am" does not.

A waiting run has the status Waiting in the run history.

---

Merging: list yes, router no

The two kinds of branching behave differently:

	Gets merged back together
Parallel — repetition over a list	yes, via Merge runs
Router — branching by conditions	no

Router branches run separately to the end

There's no merge step for the Router. Design your flows so that each branch ends on its own.

If you need the same thing at the end of several branches, add the step in each branch. Merge runs doesn't help here — it closes a Parallel section, not a Router branch.

Next

• Actions
• Data between steps
• Testing Flows