Documentation / Conception / Guides pratiques / Call a sub-workflow

Call a sub-workflow

Three core node types make a workflow callable from another one:

  • trigger.workflow-called (« Appelé par un workflow ») — the callee's entry point: each declared field (name, type, required) becomes a typed output port, fed by the caller.
  • workflow.return (« Retour ») — the callee's exit: each declared field becomes a typed input port; the values it receives are what the callee answers.
  • workflow.execute (« Exécuter un sous-workflow ») — the caller's node: pick a target workflow, wire its inputs, consume its outputs.

Build the callee

Create a workflow with the Appelé par un workflow trigger, declare its input fields in the trigger inspector, add a Retour node and declare its output fields, then wire the graph between the two. Everything in between is an ordinary workflow — including record sources (patient.*), agents, human validations.

Call it

In the caller, add Exécuter un sous-workflow and pick the target in the inspector (search + list). Picking copies the target's contract into the node: its trigger fields become input ports, its return fields become output ports. If the target's contract changes later, the ports do NOT follow automatically — reopen the node and use Resynchroniser les ports.

Any workflow is callable, not only « Appelé par un workflow » ones: for an event-triggered target (webhook, diagnostic enregistré…), the execute node's inputs are the target's trigger outputs, which you feed statically — unfed ports stay absent and absence propagates inside the callee.

Context is inherited — watch the guard

The callee runs in the caller's ambient context (patient, encounter…) against the same instance adapters: a patient.load-medications inside the callee reads the same record it would at top level. The selector flags targets whose declared context is not statically guaranteed by YOUR trigger — a webhook or workflow-called parent guarantees nothing (its context depends on what each call provides), so the warning means: make sure the identifiers (e.g. patientId) actually reach this workflow, or the callee's record nodes will fail at runtime.

How it executes, and where to watch it

The callee executes inline in the caller's durable run: its spec is frozen in the run's journal at the run's start (a later edit — or a new published version — cannot diverge a replay, and cannot change a run already in flight), its steps and pending validations are namespaced under the execute node. A callee that lives only in the definition store, never written to workflows/, is called exactly the same way — see Manage workflow storage. There is no separate entry in the runs list — in the run graph view, the execute node's card carries a « voir l'exécution » link opening the callee's own graph painted by that run (recursively, for nested calls). A human validation pending inside the callee marks the execute node « en attente » in the caller's view.

If the callee never reaches a done return node, the execute node emits nothing and the caller's downstream branch stops — ordinary absence propagation.

The callee's own trace entries land in the caller's journal, each carrying subworkflow (the target file) and calledBy (the execute node) — so two calls to the same sub-workflow in one run stay distinguishable.

Limits

  • No recursion: a workflow cannot call itself, directly or through a cycle (the run fails with the call chain), and call depth is capped at 8.
  • workflow.execute is not allowed inside a flow.map loop body — a sub-workflow per iteration would multiply durable steps and the call stack. This is a static error (meridian-plugin validate, and the editor), so it surfaces before a run, not only on the iteration that would have run it.
75 documents6 sectionssource : /docs · généré au build