Run Workflow

The Run Workflow activity starts another workflow from within the current workflow, optionally passing parameters and waiting for it to complete before continuing.

Purpose

Use the Run Workflow activity to:

• Trigger a reusable workflow from multiple parent workflows
• Chain workflows together into a multi-stage process
• Break large, complex workflows into smaller, maintainable units
• Run the same workflow with different input parameters

Configuration

Path

The full path to the workflow to run, selected via the file system picker. The path must point to a workflow file (.wf).

Example: /Workflows/Finance/MonthlyClose.wf

The path supports interpolation — you can use {{variable}} syntax to compute the path dynamically at runtime.

Stop Running Instance

When enabled, any currently running instance of the target workflow is stopped before the new one is started.

Use this when the child workflow is a singleton — only one instance should run at a time (e.g. a nightly sync job). Leaving it disabled allows multiple instances to run concurrently.

Wait for Child Workflow to Finish

• Enabled (default): The Run Workflow activity stays in Running state until the child workflow completes. The parent workflow only continues after the child finishes.
• Disabled: The activity starts the child workflow and immediately returns Success. The parent workflow continues without waiting. The child runs independently in the background.

Parameters

Key/value pairs passed to the child workflow as startup parameters. The child workflow can read these via {{param:ParameterName}} interpolation.

Both keys and values support interpolation — you can reference workflow state, context variables, and foreach items.

Field	Description
Name	The parameter name (key) as the child workflow expects it
Value	The value to pass — static text or an interpolated expression

Behavior

1. All parameter values are interpolated against the current workflow context.
2. A new run of the target workflow is started with those parameters.
3. If Wait for Child Workflow to Finish is enabled, the activity waits via Service Bus notification — it does not poll. The parent resumes as soon as the child workflow posts its completion event.
4. The child workflow inherits the scheduled-run flag from the parent (if the parent was started on a schedule, the child is treated as a scheduled run too).

Usage Patterns

Sequential Pipeline

Fetch Data ──> Transform ──> Run Workflow: "GenerateReport.wf" ──> Send Email
                                (waits for report to finish)

Fire and Forget

Run Workflow: "AuditLog.wf"
  Wait = false
  │
  └──> Continue immediately

Parameterised Reuse

Foreach: entity in entities
  └──> Run Workflow: "EntityClose.wf"
         Parameters:
           EntityId = {{foreach:item}}
           Period   = {{var:ClosingPeriod}}

Chaining Independent Stages

Run Workflow: "Stage1_Extract.wf"   (wait = true)
      │
Run Workflow: "Stage2_Transform.wf" (wait = true)
      │
Run Workflow: "Stage3_Load.wf"      (wait = true)

Comparison to Subprocess

Feature	Run Workflow	Subprocess
Defined in	Separate workflow file	Inline inside the same workflow
Reusable across workflows	✅ Yes	❌ No
Passes parameters	✅ Yes	—
Can run in background	✅ Yes (wait = false)	N/A
Appears in workflow history	Separate run entry	Part of parent run
Can be triggered independently	✅ Yes	❌ No

Usage Notes

• The child workflow is a fully independent run — it has its own run ID, its own history entry, and its own log.
• If Wait for Child Workflow to Finish is enabled and the child workflow errors, the parent activity will reflect that failure and follow the error arrow.
• If Wait for Child Workflow to Finish is disabled, the parent has no visibility into whether the child succeeded or failed.
• Parameters are passed at start time only — there is no two-way data exchange between parent and child. If you need data back from the child, write it to a shared file or database and read it in a subsequent parent activity.
• The path field is evaluated at runtime, so you can select the target workflow dynamically based on workflow state.

Best Practices

• Name the activity after the workflow it calls (e.g. "Run: Monthly Close") so the workflow diagram is self-documenting.
• Keep child workflows self-contained — they should work when run standalone, not just when called from a parent.
• Use Stop Running Instance only when the child workflow is genuinely a singleton. Enabling it unnecessarily can kill in-progress runs.
• Prefer Wait for Child Workflow to Finish = true unless the child work is truly independent — silent background failures are hard to diagnose.
• For loops over a large set, consider whether running child workflows in parallel (wait = false + downstream join) is faster than sequential chaining.

JSON Reference

{
  "discriminator": "RunWorkflowWorkflowActivity",
  "activityId": "<uuid>",
  "name": "Run Workflow",
  "positionX": 0,
  "positionY": 0,
  "advanceRule": 2,
  "dataSource": "",
  "pipelineName": "",
  "workflowPath": "/Workflows/Finance/MonthlyClose.wf",
  "stopRunningInstance": false,
  "waitForChildWorkflowToFinish": true,
  "parameters": [
    { "key": "Period", "value": "{Period}" }
  ]
}

Property	Type	Description
workflowPath	string	Corresponds to the Path field. The full Una file system path to the child workflow file to run.
stopRunningInstance	boolean	Corresponds to the Stop Running Instance toggle. When true, any currently running instance of the target workflow is stopped before the new one starts.
waitForChildWorkflowToFinish	boolean	Corresponds to the Wait for Child Workflow to Finish toggle. When true (default), the parent waits for the child to complete before continuing.
parameters	array	Corresponds to the Parameters list. Array of { "key": string, "value": string } objects passed as startup parameters to the child workflow.