Principle:Microsoft Semantic kernel Subprocess Composition
| Knowledge Sources | |
|---|---|
| Domains | Process_Orchestration, Composite_Pattern |
| Last Updated | 2026-02-11 19:00 GMT |
Overview
Subprocess composition enables nesting of processes within processes, allowing complex workflows to be decomposed into modular, reusable sub-workflows that are assembled into larger orchestrations.
Description
Subprocess Composition is the principle that allows Semantic Kernel processes to be hierarchically composed. A process defined with ProcessBuilder can itself be added as a step within a parent process using AddStepFromProcess. The child process appears to the parent as a single step, but internally it contains its own graph of steps and event routes. This creates a tree of process scopes where each level encapsulates its own complexity.
The composition mechanism works through event boundary mapping. A child process declares its own OnInputEvent routes internally. When the parent adds the child process as a step, it uses WhereInputEventIs(eventId) to map parent-level events to the child's input events. This creates a bridge between the parent's event namespace and the child's event namespace.
Events emitted by the child process with Public visibility bubble up to the parent process, where they can be captured by the parent's routing configuration using OnEvent. Events with Internal visibility remain confined to the child process scope. This visibility control allows child processes to encapsulate their internal event traffic while selectively exposing relevant outcomes to the parent.
The key benefits of subprocess composition are:
- Modularity: Complex workflows can be broken into manageable sub-workflows, each defined and tested independently.
- Reuse: A child process definition (like an account verification workflow) can be reused across multiple parent processes without modification.
- Encapsulation: Internal details of a sub-workflow are hidden from the parent. The parent only sees the child's input events and public output events.
- Separation of concerns: Different teams can develop different sub-processes and compose them at the parent level.
Usage
Use subprocess composition whenever a portion of your workflow represents a cohesive sub-workflow that can be defined independently. Common examples include verification processes (credit check, fraud detection), multi-step approval workflows, and data processing pipelines that appear as single steps in a higher-level orchestration.
Theoretical Basis
Subprocess composition implements the Composite Pattern applied to event-driven process graphs, combined with principles from hierarchical state machines.
Composite Pattern: The process builder treats individual steps and nested processes uniformly. Both implement ProcessStepBuilder and can be added to a parent process. The parent process does not need to know whether a step is an atomic step or a composite sub-process:
ProcessStepBuilder
├── ProcessStepBuilder<T> (atomic step)
└── ProcessBuilder (composite sub-process)
This uniform treatment means the parent's routing logic is identical whether routing to an atomic step or a sub-process.
Hierarchical Scope: Each process defines an event scope. Events emitted within a child process are contained within the child's scope unless explicitly marked Public:
Parent Process Scope
├── Step A (atomic)
├── Child Process Scope
│ ├── Step X (atomic) -- internal events stay here
│ └── Step Y (atomic) -- public events bubble up
└── Step B (atomic)
Event Boundary Mapping: The WhereInputEventIs method creates a mapping between the parent's event namespace and the child's external event interface:
Parent context:
formStep.OnEvent("FormCompleted")
.SendEventTo(childProcess.WhereInputEventIs("FormCompleted"))
This translates to:
Parent event "FormCompleted" → Child input event "FormCompleted"
Child internally routes "FormCompleted" to its own first step
Reuse Through Parameterization: Because child processes are defined independently, the same child process definition can be instantiated multiple times or used in different parent contexts:
// Define once
verificationProcess = NewAccountVerificationProcess.CreateProcess()
// Use in multiple parents
parentA.AddStepFromProcess(verificationProcess)
parentB.AddStepFromProcess(verificationProcess)
The child process is a template: adding it to a parent produces a new instance within that parent's execution scope.