Collections and loops
Prepare typed lists with explicit operations, then choose between Each to repeat a node and Foreach to launch an autonomous child process for each element.
Typed collections
A value array<platform.invoice> does not become a generic JSON array when it passes through a collection node. Operations preserve or explicitly derive the concrete element type, so the editor can keep offering valid fields and relationships in subsequent bindings.
Prefer these nodes to expressions when the operation is a common transformation: intent remains visible in the graph, output type remains explicit, and cardinality errors are treated as product guarantees.
Transformer puis parcourir
Prepare the collection first, then choose the right execution granularity: Each repeats one node in the same instance; Foreach launches autonomous child instances.
filter_order, take, or distinct decide which elements remain in the collection. Each and Foreach then decide how work is executed for those elements.
Collection nodes
| Node | Role | Useful guarantee |
|---|---|---|
filter_order | Filtrer puis trier. | Preserves the concrete element type and stable ordering. |
take | Limit the list. | Returns at most N elements without changing their type. |
exactly_one | Transform T[] into T. | Fails when the collection contains 0 or more than 1 element. |
first_item | Take the first T. | Fails only when the collection is empty. |
distinct | Deduplicate. | Can use business fields and choose whether to keep the first or last duplicate. |
concat | Concatenate two lists. | Unifies compatible types and preserves left-then-right order. |
partition | Split according to conditions. | Each element appears in exactly one of the two outputs. |
check_if uses the same condition language as filter_order and partition, but routes a single object; it therefore belongs to Routing and decisions.
Each: repeat a node within the same instance
When a node accepts an object T but your source is a collection T[], enable Each
in the binding. The node executes once per element without creating a separate child process.
- The
Ttype is preserved during every iteration. - Element outputs are reaggregated into typed collections.
- Retries and warnings remain observable at node-iteration level.
- The same process instance carries the whole execution.
Use Each when the logic to repeat fits in one node — for example, send the same type of action to every object in a collection.
Foreach: one autonomous child instance per element
foreach launches one child process per element. Each child has its own graph, execution state, and observability. This isolation fits processing that spans multiple steps, waits, human interactions, or logic deserving its own revision.
| Policy | Parent behavior | When to use |
|---|---|---|
wait_for_all | Waits for all child instances to resolve before continuing. | Continuation depends on the overall fan-out result. |
no_wait | Starts children and then continues without waiting for their resolution. | Children are autonomous and parent continuation does not need their results. |
Participants, user actions, and internal states of child processes remain independent. The parent observes their resolution but must not assume their internal data automatically becomes shared variables.
Patterns usuels
- Select the top N priorities:
filter_order → take. - Require an unambiguous match:
filter_order → exactly_one. - Keep a deterministic fallback: trier explicitement puis
first_item. - Process two populations:
partitionproduces thematchingandremainingcollections without duplicating the rule. - Controlled fan-out: clean/deduplicate the list, limit it if necessary, then
foreach.
The Core node catalog documents the exact parameters of these primitives; this page remains the reference for choosing their composition.