> For the complete documentation index, see [llms.txt](https://docs.rubica.au/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rubica.au/workflow-automation/parallel-sub-jobs.md). # Parallel Sub-Jobs Launch several sub-workflows from one outcome — Super, Investment, Insurance — and hold the master Job until they're all done. Some outcomes shouldn't just move a Job forward — they should kick off two or three separate workflows and wait for **all** of them before moving on. "Implementation" is the classic case: advice gets signed, and Super, Investment and Insurance each need their own workflow, their own owner, their own due date — but nobody should be reviewing the file until every stream is actually finished. This is a **Job**-type Stage Action attached to an outcome, with two extra settings turned on: **Wait for the sub-job to complete** and **Adviser chooses whether to run**. Nothing else changes — it's the same Job action you already use to launch a single related workflow (see [Action Types Reference](/workflow-automation/action-types-reference.md)), just able to launch several and hold the parent open until they're done. ## What it looks like to the adviser 1. The adviser picks the outcome, e.g. **"Do Implementation Work."** 2. A **"Which sub-jobs should start?"** picker opens — one checkbox per sub-workflow, each showing who'll own it. The adviser unticks anything that doesn't apply to this client. 3. Confirming creates one sub-job per ticked box, and the master Job **stays on its current stage** — the outcome button that started this is effectively "pending" until every ticked sub-job reaches its own Completed (or Voided) state. 4. The Job panel shows a **Sub-jobs** card: each stream's owner, current stage and status, plus a progress bar ("1 of 3 done · 33%"). 5. The moment the last one finishes, the master Job **moves on by itself** — wherever that outcome was configured to go (another stage, or Close Job). Nobody has to come back and click anything. Un-ticked sub-workflows are recorded in the Job's history as "Not selected by \", so there's always an audit trail of what didn't run and who decided that. {% hint style="info" %} If the adviser ticks nothing, the outcome just moves the Job on immediately — the hold only ever applies while at least one sub-job is still open. {% endhint %} ## Setting it up **Home → Settings → Workflow Templates →** a template **→ Stages** tab **→** open the stage **→** find the outcome under **How stage ends** **→ +** to add an action **→ Job**.
| Field | What it does | | --------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Sub-workflows the adviser can choose from** | Search and add every Job Template this outcome might launch — Super Implementation, Investment Implementation, Insurance Implementation. Each becomes one checkbox in the picker. This replaces the plain "Job Template" field you'd normally see — it only appears once **Adviser chooses** (below) is on. | | **Wait for the sub-job to complete** | The join gate itself. On: the outcome holds the master Job on its current stage until every launched sub-job is Completed or Voided. Off: fire-and-forget — the sub-job is created and the outcome moves the Job on straight away, same as a plain Job action always has. | | **Adviser chooses whether to run** | Turns on the picker. Off: every configured sub-workflow always starts, no choice offered. | | **Ticked by default** | Only shown once Adviser chooses is on. On: the picker opens with every box ticked, and the adviser removes what doesn't apply. Off: opt-in — nothing's ticked until the adviser adds it. | One action, one picker: add every sub-workflow this outcome might need to the **same** Job action rather than creating a separate action per template — that's what makes the picker show them all together instead of asking the adviser to confirm three separate times. {% hint style="warning" %} **Only Job actions attached to an outcome** get the adviser-picker toggles. A Job action added at the plain stage level (fires the moment the stage is entered, nobody has picked anything yet) has nobody to ask, so it keeps the single Job Template field and no picker — see [Stage Actions — Overview](/workflow-automation/stage-actions-overview.md) for the stage-level vs outcome-attached distinction. {% endhint %} ## How the hold and auto-advance actually work This reuses the outcome mechanics you already know, it just adds one more thing an outcome can be waiting on: * Every child Job created this way is linked back with **Source Job** set to the parent — visible as a "Part of: \" breadcrumb on the child's own Job panel. * The master Job is genuinely held — the pending-action gate that normally stops a Job moving while an Email or Screen Flow is still open now also covers open sub-jobs. * A **second, different outcome** on the same stage is blocked while sub-jobs are open, so nobody can accidentally route the Job away and strand the running streams. The block names which outcome is holding it. * Once the last sub-job resolves, the **same outcome** that started the hold completes its own routing — same Next Stage / Close Job you configured, same on-entry actions, same audit-feed line an adviser clicking it manually would produce (just credited to "Workflow automation" instead of a name). ## What if the adviser wants to check on it manually? The **Sub-jobs** card on the Job panel is always there once any sub-job is running or was launched from the current stage — click **Open →** on any row to jump straight to that child Job. There's no separate report; the card and each child's own progress bar are the whole picture.
## See also * [Stage Outcomes](/workflow-automation/stage-outcomes.md) — outcomes, Next Stage, and what "attached to an outcome" means * [Action Types Reference](/workflow-automation/action-types-reference.md) — the plain, single-target Job action * [Stage Actions — Overview](/workflow-automation/stage-actions-overview.md) — timing, recipients and conditions shared by every action type