Run: <PipelineName>
Description
Runs another pipeline in the same organization. The target must carry a Called by pipeline trigger; its declared trigger parameters appear as typed input pins. One execution-intent row is enqueued and a NOTIFY wakes the cluster, so any instance can claim and run the target. Asynchronous by default; tick Wait for completion to block until the target finishes and route to Error if it did not succeed.
When to use
Use Run pipeline when exactly one other pipeline should run. It is the counterpart of Send signal, and the difference is addressing: a signal is a broadcast, so the sender names an event and every subscriber runs, while a call names one pipeline. Reach for a signal when any number of pipelines may care about something that happened; reach for a call when you know which pipeline should do the work.
It is also how a managed pipeline copy is driven. Installing a managed pipeline gives you a named copy per configuration — “Prod” and “Test”, say — and a call can target one of them specifically.
The input pins come from the target’s trigger-parameter declaration. Leaving one unwired passes an explicit null, which is why the matching pin on the target’s Called by pipeline node is always nullable.
The Error pin fires when the target cannot be reached: it no longer exists, it has lost its Called by pipeline trigger, or it is inactive. By default it does NOT fire when the target runs and fails — the call finishes as soon as the run is queued, so the target’s own outcome is visible only in its execution history.
Tick Wait for completion to change that. The node then blocks until the called pipeline reaches a final state and takes the Error pin if it ended as anything other than a clean completion — failed, timed out, cancelled, rejected by a plan limit, or blocked because the target was halted. The log names the pipeline and the state it ended in. There is still no result value: waiting reports whether the call succeeded, not what it produced.
Waiting has two limits worth knowing. A waiting caller stays RUNNING for the whole wait, and an execution is timed out after ten minutes, so Wait timeout (s) is capped at 540 seconds. And waiting turns a cycle into a deadlock, so a chain of waiting calls is refused past three deep — if you see that error, two pipelines are waiting on each other.
Pins
Input pins
| Pin | Type | Default | Notes |
|---|---|---|---|
| Wait for completion | boolean | — | Off by default. When on, the node blocks until the called pipeline reaches a final state, then continues on Error if it did not complete cleanly. |
| Wait timeout (s) | integer | 300 | How long to wait before giving up and taking the Error pin. Capped at 540 seconds, because a waiting caller stays RUNNING and executions are timed out after ten minutes. Ignored while Wait for completion is off. |
Execution pins
| Pin | Direction |
|---|---|
| In | Input |
| Out | Output |
| Error | Output |
Example
A nightly pipeline gathers changed products, then ends with Run: Viskan products — Prod, passing the array into the products pin. A second, manually triggered pipeline ends with Run: Viskan products — Test so the same integration can be exercised against a test instance. Both calls return immediately; each run appears in the target copy’s own execution list, marked as called by a pipeline.
An orchestrating pipeline wants the opposite: it ticks Wait for completion on Run: Import products, so the next step only runs once the import is finished, and the Error pin catches an import that failed.