Parallel Processes
Parallel processes let a parent workflow spawn child process instances that run independently with their own state, parameters, and lifecycle. Fork transitions defined by nesting levels within one scheme separate parent from child. Parameters flow through configurable copy and merge strategies.
Most business processes have steps that happen at the same time. A purchase order may need three separate approvals from different departments. An onboarding workflow may provision accounts in five systems simultaneously. Without parallel processes, you either model every combination as a linear sequence or split the workflow into disconnected pieces that must be tracked separately.
Parallel processes let a parent workflow spawn child process instances that run independently. Each child has its own state, its own parameters, and its own activity lifecycle. The parent can continue independently or coordinate with children when they finish. The children are full process instances - they can branch, use timers, and even spawn their own children.
With parallel processes, you model concurrent work where it belongs - inside the same workflow. A procurement workflow spawns a subprocess for each line item review; reviews run in parallel, and the parent proceeds to fulfillment only when all are complete.
What it is
Think of parallel processes like delegating tasks to a team. You assign work to several people at once, each works independently, and you collect the results when everyone is done. You do not need to know exactly how each person does their work - you just need the outcome.
Workflow Engine models parallel processes using fork transitions. A fork transition is a special transition that creates a child process instance. The parent scheme contains parent activities at a lower nesting level and child activities at higher levels, with fork transitions connecting them. When the parent enters a transition from a lower nesting level to a higher one, the runtime creates a child process instance - the subprocess starts. When the child completes and a transition goes back to a lower nesting level, the runtime merges the child back into the parent - the subprocess ends.
Each child runs as a full process instance with its own state and its own parameters. The child scheme is derived from the same built scheme definition as the parent - activities at different nesting levels within that scheme separate the two. To reuse a separately authored scheme fragment, add it to the parent as an Inline Activity. During scheme build, Workflow Engine copies the fragment into the root scheme before the runtime extracts and versions the subprocess definition. Parameters flow between parent and child through configurable copy and merge strategies: you decide which parameters the child inherits at startup and which it sends back on completion.
For developers: fork transitions are configured by setting IsFork = true on a TransitionDefinition. The ForkType (ForkStart or ForkEnd) is determined by the nesting levels of the From and To activities. Reusable external fragments must be incorporated through scheme inlining before those subprocess boundaries are built. Subprocess startup behavior is controlled by SubprocessStartupType (SameThread, AnotherThread, TimerQueue). Parameter passing is configured via SubprocessStartupParameterCopyStrategy and SubprocessFinalizeParameterMergeStrategy. See Configure Subprocesses for implementation guidance.
Why it matters
Parallel processes deliver these outcomes:
Concurrent work in a single workflow - model parallel approvals, multi-system provisioning, or simultaneous document reviews without splitting your process into disconnected pieces. The runtime tracks all children as a tree, and the parent can use completion conditions to wait for the required branches.
Independent state per branch - each child has its own parameters, activity state, and execution timeline. One child waiting for a manager approval does not block another child running an automated check. Children can use timers, conditions, and subprocesses of their own.
Configurable parameter isolation - choose which parameters the child inherits from the parent (all, none, or a specified list) and which it merges back on completion. Unmapped parameters stay private to each process instance.
Reusable process fragments - define a fragment in a separate scheme and insert it into parent workflows through scheme inlining. The build step embeds the fragment into each root scheme, so the runtime still creates every subprocess from one combined scheme definition.
Who it is for
Evaluator (CEO, CTO, PM): parallel processes eliminate the complexity of splitting concurrent work across multiple workflow definitions. A single process definition models the entire flow, including parallel branches, without requiring custom orchestration code outside the workflow engine.
Developer: subprocesses are configured through fork transitions in the scheme. The runtime handles child instance creation, parameter isolation, and merge on completion. You control execution strategy (same thread, separate thread, or timer queue) and parameter passing. See Configure Subprocesses for setup.
Enterprise architect: each child process instance is persisted independently with its own scheme version. The parent and children are linked through the process instances tree, which is stored and queryable. Parameter isolation prevents data leakage between branches while allowing explicit data flow where needed.
When to use it
Use parallel processes when a unit of work has its own lifecycle, its own state, and its own completion criteria that differ from the parent workflow. Typical examples:
Multi-department approvals - a purchase order requires approval from finance, legal, and operations simultaneously. Each department's review is a subprocess; the parent order waits for all three before proceeding to fulfillment.
Multi-system provisioning - an employee onboarding workflow provisions accounts in HR, IT, and facilities systems in parallel. Each system integration is a subprocess that completes independently.
Reusable workflow fragments - the same compliance review applies to orders, contracts, and vendor onboarding. Define it as an inlineable scheme and reference it through an Inline Activity in each parent. Saving the fragment through the Designer marks related parent schemes obsolete, so their next built versions include the update while running instances follow normal scheme-versioning rules.
Parallel data processing - a document processing pipeline splits a batch into individual items, processes each item independently, and merges results when all items complete. Each item is a subprocess with its own progress tracking.
How it compares
There is no built-in alternative to parallel processes in Workflow Engine. Each parallel branch is represented as a full process instance within the same scheme definition. If you need concurrent work that has its own state, lifecycle, and completion criteria, subprocesses are the mechanism - there is no separate feature that provides the same capability.
The only alternative is to model concurrent work externally: create separate process instances from your application code and coordinate them manually. This requires custom orchestration logic and loses the parent-child relationship tracking that the runtime provides.
Frequently asked questions
How do parallel processes compare to running separate process instances from code?
Running separate process instances from application code gives you concurrent execution, but you lose the built-in parent-child relationship. With subprocesses, the runtime tracks the hierarchy, applies configured parent-state control, and can merge parameters on completion. Manual orchestration requires you to implement these relationships yourself.
Can a subprocess spawn its own subprocesses?
Yes. Each child is a full process instance. It can have its own fork transitions, timers, conditions, and subprocesses. The runtime tracks the entire hierarchy through the process instances tree and enforces parent-child lifecycle rules at every level.
How do I pass parameters between parent and child?
The fork transition defines a startup parameter copy strategy and a finalize parameter merge strategy. At startup, you choose whether the child inherits all parent parameters, none, or only a specified list. On completion, you choose whether child parameters overwrite parent parameters, only null values, or a specified list. Parameters that are not explicitly passed are isolated to their process instance.
What happens to subprocesses if the parent completes or is cancelled?
The runtime checks subprocess validity whenever the parent changes state. If a parent moves to a state where the subprocess can no longer exist, the runtime drops the subprocess. You can disable this behavior per fork transition by setting DisableParentStateControl to true, which gives you full control over subprocess lifecycle.
Can I use a separate scheme as a subprocess?
Not directly. Add the separate scheme as an Inline Activity in the parent; the build step embeds its elements into the root scheme, and fork transitions then create the subprocess from that combined definition. Saving the inlined scheme through the Designer marks related parent schemes obsolete so new built versions can include the change.
Can I control when a subprocess starts - on the same thread, a new thread, or a timer?
Yes. The SubprocessStartupType property on the fork transition controls this. SameThread creates the child synchronously during the parent's command execution. AnotherThread creates the child on a background thread. TimerQueue schedules child creation through the timer queue for deferred execution.