Overview

By default, activities in a Matrix42 workflow are executed sequentially: each activity starts only after the previous one has completed. For scenarios where multiple independent operations can run simultaneously, Workflow Studio provides several mechanisms for parallel execution.

Parallel execution can significantly reduce the total execution time when processing multiple independent tasks, such as:

• Processing multiple objects simultaneously.
• Calling multiple external services in parallel.
• Executing independent business logic branches concurrently.
• Starting background workflows without blocking the current workflow.

Workflow Studio supports three approaches for parallel execution:

1. ParallelForEach
2. Parallel
3. Run Sub-Workflow with “Do not wait” enabled

ParallelForEach

The ParallelForEach<T> activity executes the same workflow logic for multiple items concurrently. Each item from the provided collection is processed in its own parallel branch.

This activity is best suited when the same operation must be applied to many objects independently.

Typical use cases include:

• Updating multiple Configuration Items
• Creating multiple Service Desk tickets
• Synchronizing several users with an external system
• Processing records returned from Get Multiple Records

Properties

Values – Collection of items to process.
TypeArgument – Type of objects in the collection Values.
CompletionCondition (optional) – Stops scheduling new iterations when the specified condition evaluates to True.

Example

A workflow retrieves 500 assets from the CMDB and updates each asset independently.

Instead of processing all assets sequentially with For Each Workflow Activity the workflow uses ParallelForEach, allowing multiple assets to be processed simultaneously.

Parallel

The Parallel activity executes several different workflow branches simultaneously. Unlike ParallelForEach, each branch may contain completely different workflow logic.

Typical scenarios include:

• Calling several REST APIs in parallel.
• Running multiple validation routines simultaneously.
• Performing logging while business logic continues.
• Executing independent calculations.

The workflow continues after all branches have completed unless a CompletionCondition  expression is configured and returns True

Since these operations do not depend on one another, executing them concurrently reduces the overall workflow duration.

Run Sub-Workflow (Asynchronous)

The Run Sub-Workflow activity provides another way to achieve parallel execution.

When the Do not wait property is enabled, the parent workflow starts the child workflow asynchronously and immediately continues with the next activity without waiting for the child workflow to finish.

This approach is useful for long-running or background operations that should not delay the main workflow.

Typical scenarios include:

• Sending large batches of emails
• Generating reports
• Importing data
• Background synchronization jobs
• Audit or logging workflows

Properties

Workflow – Workflow to execute.
Arguments – Input and output parameters.
Do not wait – Starts the sub-workflow asynchronously.
Ignore Failure – Continues execution even if the sub-workflow fails.

Example

A service request workflow:

1. Creates a Service Request.
2. Starts a reporting workflow asynchronously.
3. Continues with approval processing immediately.

The user does not need to wait until the reporting workflow completes.

Pick (Event-Driven Parallel Execution)

The Pick activity allows a workflow to wait for multiple alternative events or conditions at the same time and continue with the first one that becomes available. This behavior is similar to a race between several branches. Only one branch is executed — the branch that is triggered first. All other waiting branches are cancelled.

A Pick activity consists of one or more PickBranch activities.

Typical use cases include:

• Wait for either an approval or a timeout.
• Wait for one of several external events.
• Implement SLA escalation logic.
• Wait for a user response or automatic cancellation.
• Handle competing workflow triggers.

Example: Approval with Timeout

A common pattern is waiting for a manager approval while also enforcing a timeout.

Behavior:

• If the manager approves within 48 hours: the Approval branch wins and the Timeout branch is cancelled.
• If no approval is received within 48 hours: the Timeout branch wins and the approval waiting branch is cancelled.

PickBranch

Each PickBranch contains:

Trigger – an activity that waits for an event or condition.

Action – the workflow logic that is executed when the trigger completes first.

The workflow engine monitors all PickBranch triggers in parallel. As soon as one trigger completes, its corresponding Action is executed and the remaining branches are cancelled.

Choosing the Right Approach