Embed another workflow with a Workflow Container

A Workflow Container runs another workflow as a single step inside the current one. Build a reusable workflow once (a standard end-of-day sequence, say) and call it from many parent workflows instead of rebuilding it each time. It runs inside the platform, so it needs no agent.

What this solves

The same sequence (a standard end-of-day close, a shared validation routine) gets rebuilt inside every workflow that needs it, so each copy drifts and a single fix has to be made in many places.

Use it when

• You have a sequence used by several workflows and want to maintain it in one place.
• You want to break a large workflow into smaller, reusable pieces.

Mark the workflow you want to embed as a sub-workflow

The container's picker lists sub-workflows only, so start with the workflow you want to embed:

1. Go to Workflows and open the workflow to be embedded.
2. On the Overview panel, turn on Sub-Workflow.
3. Save the workflow, then version and deploy it as usual.

Sub-Workflow is the first switch in the Multi-Instance section, above Allow Multi-Instance — because turning it on is what locks the switch beneath it. It declares that this workflow runs only as a container's child: hidden from the Schedule Workflow dialog and refused for a direct build, which is what stops someone running a shared sequence directly by mistake. Allow Multi-Instance is turned on and locked while the flag is set, because one parent may invoke the same sub-workflow more than once on a date.

A sub-workflow can't be deleted out from under its parents

A Workflow Container job that embeds a workflow now counts as a reference to it, so the sub-workflow's Cross Reference lists every container using it and its delete is blocked while any of them exist. Previously only cross-workflow dependencies counted, so a sub-workflow embedded by three containers and depended on by none reported nothing referring to it.

The same holds for renaming it, and for its deployment: while a deployed parent embeds this workflow, you cannot rename it, remove its deployment from that environment, or narrow that deployment's date window.

Deploy the sub-workflow before the parent

A parent cannot be deployed to an environment where its sub-workflow is not deployed, or where the sub-workflow's date window doesn't cover the parent's. Step 3 above is therefore a prerequisite, not housekeeping — the parent's Deploy modal disables Set-up Deployment and says which sub-workflow is missing. See A sub-workflow must be deployed wherever its parent is.

Add a Workflow Container to a workflow

To add a Workflow Container, complete the following steps:

1. Go to Workflows and open the workflow you want to edit.
2. Add a job: on an empty workflow select First Job, otherwise select New Job from the Job Tools panel.
3. In the job editor, select the Job Definition tab.
4. Select Show Job Types.
5. In the job type catalog, under Internal, select Workflow Container.
6. Under Job Parameters, in Sub-Workflow, start typing to search your sub-workflows and select the one to embed. Only workflows marked Sub-Workflow are offered, and the workflow you're currently editing isn't, so you can't point a workflow at itself.
7. Select Save & Close.

Once the job holds a reference, Open in New Tab — from the job card's menu on the canvas, or from the canvas context menu — opens the sub-workflow in a new browser tab, so you can check the thing you're embedding without losing your place. It reads the reference as it stands in the editor, so a target you just changed is the one that opens, and it stays available even when the canvas is read-only.

Finding sub-workflows in the workflow list

The Workflows picker groups results under Workflows and Sub-Workflows, with a filter chip for each kind and a Sub-Workflow badge on the rows. Un-press Workflows to see only the sub-workflows; the choice sticks for the rest of your browser session. Un-pressing both is ignored, so the list never goes empty on you.

Settings

Setting	Notes
Sub-Workflow	The sub-workflow to embed. Required. Chosen from a searchable picker, which stores the workflow's identifier alongside its name. It must be deployed and effective for the dates the parent workflow runs.
Sub-Workflow (on the embedded workflow's Overview panel)	Marks a workflow as embeddable-only: hidden from Schedule Workflow, refused for a direct build, and the only kind the container picker offers.

Good to know

• The embedded workflow is built when the parent is built, not when the container job runs — so after a build you can see the whole hierarchy, several levels deep, before anything starts. Each nested run waits on its container job until that job runs.
• The container stays running until the embedded workflow finishes, then settles to match.
• Each nested run is named for where it sits: Parent_ContainerJob[Child], so two runs of the same sub-workflow under different containers are easy to tell apart.
• Because the picker stores the workflow's identifier, renaming the embedded workflow later doesn't break the container.
• A workflow can't embed itself or any workflow that already contains it (no loops), including indirect ones — A embedding B that embeds A — and nesting has a depth limit (10 levels by default).
• If a platform service is briefly unavailable, the container waits and retries on its own rather than failing. If it passes its start time while waiting, it shows as Late to start.
• If a container's sub-workflow can't be built, the rest of the build still succeeds — the parent's own jobs are fine. Scheduling the parent warns you on the Processes page, naming the container job and the reason, and the container job carries a warning icon in the Job View and on the workflow diagram until it's resolved. Most often the reason is that the embedded workflow isn't deployed for that date.
• Deleting or rebuilding the parent takes the whole nested hierarchy with it.
• When troubleshooting, remember a single job may be an entire embedded workflow. Follow it to the nested run.

Related topics

• Workflow Container job — full configuration reference and troubleshooting
• Use a Null Job (Builder)
• Respond to a failed connector job (Operator)