Principle:Microsoft Semantic kernel Process Control Flow
| Knowledge Sources | |
|---|---|
| Domains | Process_Orchestration, Event_Driven_Architecture |
| Last Updated | 2026-02-11 19:00 GMT |
Overview
Process control flow governs how conditional branching, iterative loops, and process termination are implemented within event-driven process workflows through selective event emission.
Description
Process Control Flow is the principle that defines how non-linear execution patterns are achieved within Semantic Kernel's process orchestration framework. Unlike traditional imperative code where control flow is expressed through if/else, while, and return statements, process control flow is expressed through the selective emission of events from within step functions. A step decides which event to emit based on runtime conditions, and the process routing configuration determines which step receives each event, thereby controlling the flow of execution.
This event-driven control flow model supports three fundamental patterns:
Conditional Branching: A step emits different events based on runtime conditions. The process routing maps each event to a different downstream step or function. For example, a validation step might emit ValidationPassed or ValidationFailed, each routed to a different handler.
Iterative Loops: A cycle in the process graph creates a loop. When step A emits an event that routes to step B, and step B emits an event that routes back to step A, the process iterates until one of the steps emits a different event that breaks out of the cycle. This is how conversational loops (user input, AI response, user input again) are modeled.
Process Termination: A step can signal the end of the process in two ways. The step can emit an event that is routed to StopProcess() in the process definition, or the step can emit an event that simply has no downstream target, causing the process to complete naturally when all pending events are consumed.
The key insight is that control flow logic lives inside the step (deciding which event to emit), while the routing topology lives outside the step (in the process builder definition). This separation means:
- A step's branching logic is self-contained and testable
- The same step can participate in different process topologies with different routing outcomes
- The process graph can be visualized and reasoned about independently from the step implementations
Usage
Use selective event emission within step functions whenever the process flow depends on runtime conditions. Define the corresponding event routes in the process builder to map each possible event to its target. Use StopProcess() for termination routes and cyclical SendEventTo routes for loops.
Theoretical Basis
Process control flow in Semantic Kernel maps directly to concepts from Petri nets and event-driven state machines.
Event-Driven Branching as Exclusive Choice: When a step emits one of several possible events based on a condition, this implements the Exclusive Choice (XOR-split) workflow pattern:
Step.Execute(context, input):
if condition_A(input):
emit Event_A(data_A) // Branch A
elif condition_B(input):
emit Event_B(data_B) // Branch B
else:
emit Event_C(data_C) // Branch C
Process routing:
Step.OnEvent("Event_A") → HandlerA
Step.OnEvent("Event_B") → HandlerB
Step.OnEvent("Event_C") → HandlerC
At most one branch is taken per execution of the step, because the step logic determines which single event to emit.
Cycles as Structured Loops: A loop is created when the routing graph contains a cycle. The loop continues as long as the step within the cycle continues to emit the event that re-enters the cycle:
Process graph cycle:
UserInputStep.OnEvent("InputReceived") → ResponseStep
ResponseStep.OnEvent("ResponseGenerated") → UserInputStep
Loop termination:
UserInputStep.OnEvent("Exit") → StopProcess()
Execution trace:
UserInput → Response → UserInput → Response → ... → Exit → STOP
The loop has no fixed iteration count; it terminates when the step emits the exit event. This models open-ended interactions like chat conversations where the number of turns is not known in advance.
Termination as Sink Node: StopProcess() creates a sink node in the execution graph. When an event is routed to this sink, the process runtime drains all pending events and completes:
Graph G with sink:
V = {Start, Work, End, STOP}
E = {Start→Work, Work→End, End→STOP}
STOP has out-degree 0 (no outgoing edges)
Multi-Event Emission: A step can emit multiple events in sequence within a single function execution. Each emitted event is independently routed, enabling parallel fan-out at decision points:
Step.Execute(context, input):
emit Event_A(data_A) // Routed to Handler A
emit Event_B(data_B) // Routed to Handler B simultaneously
This corresponds to the AND-split (parallel split) workflow pattern, where a single step activation produces multiple concurrent downstream activations.