Start Other Pipeline

Purpose and Use Case

The Pipeline Trigger worker (zbs.pipeline.caller, module zbsync) lets one pipeline start another pipeline mid-run — the "sub-pipeline" — optionally waiting for it to finish and merging its output back into the parent pipeline's data.

This is the dedicated worker for chaining pipelines together. For other ways to trigger a pipeline (cron jobs, UI buttons, HTTP endpoints, method/field triggers, or calling zbs.pipeline methods directly from a Python Code Worker), see Starting a Pipeline.

Configuration

Field	Description
Pipeline to Call	The sub-pipeline to start. Required — the worker raises an error if left unset.
Mode	Fire and Forget, Wait Until Done, or Return Data — what this worker does after launching the sub-pipeline. See below.
Call Mode	Start in background (default) or Start and execute — how the sub-pipeline is launched. See below.
Data Field	zSYNC code that computes the data payload passed to the sub-pipeline. Leave empty to pass all of the current input data through unchanged.

How It Works

Call Mode: launching the sub-pipeline

• Start in background — creates a pending sub-pipeline instance for the cron/queue mechanism to pick up asynchronously. Because that pending instance only becomes visible after a commit, this worker always needs one extra heartbeat/retry cycle after launching before it can move on to checking the sub-pipeline's state — this happens transparently, but means at least one scheduler interval elapses even in Fire and Forget mode.
• Start and execute — runs the sub-pipeline synchronously, inline, in the same request. If the sub-pipeline fails, the error is raised immediately.

Mode: what happens after launching

Mode	Behavior
Fire and Forget	Doesn't wait for the sub-pipeline at all. The worker continues immediately (after the one required heartbeat when using Start in background), passing its original input data through unchanged.
Wait Until Done	Pauses (polling on each heartbeat) until the sub-pipeline reaches Success or Failed, then continues — passing the original input data through unchanged either way. A failed sub-pipeline does not raise an error and its output is not retrieved.
Return Data	Pauses until the sub-pipeline reaches Success; if it reaches Failed instead, raises an error that aborts the parent pipeline. On success, merges the sub-pipeline's output records into the corresponding input records, matched by position.

Return Data pairs naturally with the Keep Input option on this worker, so fields from the original record aren't lost when the sub-pipeline's output replaces/enriches the data.

Usage and Best Practices

Common Pitfalls

• Pipeline to Call left unset raises Pipeline not set as soon as the worker runs.
• Wait Until Done hides sub-pipeline failures — it neither raises an error nor returns any data from a failed sub-pipeline run. If the parent needs to react to the sub-pipeline's success/failure or use its output, use Return Data instead.
• Return Data merges by position, not by any key — the sub-pipeline's output records are paired with the parent's input records purely by matching index. If the sub-pipeline changes the number or order of records, records at indexes with no counterpart are silently left un-enriched rather than raising an error.
• Start and execute blocks the parent for the full duration of the sub-pipeline run — prefer Start in background for long-running sub-pipelines to avoid tying up the parent's execution.

Performance Tips

• Use Data Field to send only the subset of data the sub-pipeline actually needs, instead of the full input set, especially when triggering the same sub-pipeline once per record in a loop.
• Fire and Forget with Start in background is the lightest option when the parent doesn't need to know the outcome — it only costs the one extra heartbeat to hand off the job.