XeniaXenia Docs

Flow Control

PreviousNext

The nodes that shape the flow itself, fanning out, looping, or bringing paths back together.

Flow control nodes change the structure of a journey rather than what it says to anyone. None of them sorts customers, and only Merge and Router accept more than one incoming connection.

Parallel

Runs several branches at once, for the same customer. Use it when independent things should all happen and the order between them does not matter, such as notifying the customer, updating the CRM, and syncing an audience.

Configure

SettingWhat it does
BranchesThe branches to run at once. Add and remove them
Failure modestop-on-first-error abandons the journey as soon as a branch fails, continue-on-error carries on, stop-if-all-fail continues while at least one branch succeeds

Outputs

One output per branch. Before any branch is configured, the node renders A and B.

Watch out

  • Every branch runs for every customer. This is not a way to sort anyone: if only one branch should run, use a Rule.
  • Use a Merge node if later nodes should wait for all branches to finish.

Iterate

Loops over each item in a list, then carries on. Use it when an earlier node returned a list and each item needs the same treatment.

Needs upstream

A node producing a list, such as an API Request with an array response, or an Audience Lookup set to GET_ALL.

Configure

SettingWhat it does
Items to iterateThe variable holding the list, for example {{response}}
Batch sizeHow many items to process at a time

Required: the variable.

Outputs

Loop (each item) runs once per item. Done (after all) runs once after every item.

Produces

Inside the loop, {{response.value}} is the current item and {{index}} is its position.

Watch out

  • The two outputs mean different things and are easy to swap: a message on done sends once, the same message on loop sends per item.
  • Iterate runs nodes inside one customer's run. It enrols nobody, so it is not the way to put a list of people through a journey.

Merge

Brings several paths back into one, so paths that split earlier continue identically from here instead of needing a copy of the ending per path.

Configure

SettingWhat it does
Join modeWAIT_FOR_ALL waits for every incoming path, ANY continues on the first arrival

Nothing is required: an unset join mode behaves as WAIT_FOR_ALL.

Watch out

  • This is the only node that accepts more than one incoming connection. Everywhere else, pointing a second path at a node is rejected, so merge first.
  • Nothing is held open. If the threshold is never met the journey ends at the merge, so after a Rule, where only one path ever runs, WAIT_FOR_ALL silently drops everyone. Use ANY there.
  • With WAIT_FOR_ALL after a Parallel, every branch's variables are available downstream. With ANY, the slower branches' variables will not be there.

Router

Gives each incoming path its own follow-up, showing one lane at a time to keep a busy canvas readable. It adds no behaviour: it is a readability node.

Configure

SettingWhat it does
LanesOne lane per incoming connection, created by drawing that connection
Auto focusFocus the lane that was just connected
Show allShow every lane at once instead of one

Watch out

  • Only you can add and wire a Router. Its lanes come from connections drawn on the canvas, so a lane cannot exist before its connection does, and the Build with AI panel cannot create one.
  • If the paths should converge on the same nodes from here, that is a Merge.