Create a durable process instance with a stable business identity and the state needed to make later decisions.
Enterprise Messaging · Message Routing
Process Manager
Use a stateful coordinator that tracks process progress and determines the next action from business state, events and completion rules.
How do we route a message through multiple processing steps when the required steps may not be known at design-time and may not be sequential?Adapted from Enterprise Integration Patterns under CC BY 3.0. The visualization and explanatory content on this page are original GateSift material.
Original GateSift visualization
How Process Manager works
A dedicated coordinator owns durable integration state and decides which message or operation should happen next as a multi-step conversation progresses.
Long-running conversation
Persist and coordinate state
Next step
Complete
Recover
Advance the process from incoming results, timeouts or events without moving participating domain logic into the coordinator.
Complete, compensate or escalate stalled instances with enough telemetry for operators to understand their current state.
Curated GateSift guidance
When this pattern is a good fit — and when it is not
Use a process manager when one component must coordinate a multi-step integration conversation and make explicit decisions about what happens next based on accumulated state.
- A long-running flow spans several messages, APIs or systems and requires durable coordination state.
- The next action depends on outcomes from earlier steps rather than on one message alone.
- Centralized orchestration makes the business process easier to reason about than distributed event choreography.
- A simple stateless pipeline or broker subscription can express the flow without central coordination.
- The coordinator would become responsible for domain logic that belongs inside participating services.
- A single orchestration would grow into a monolith controlling unrelated business processes.
Stuck stateHigh impact
Long-running instances need timeouts, ownership and recovery for work that never completes.
Coordinator bottleneckReview
Central orchestration can become a throughput or availability dependency for otherwise independent services.
State compatibilityHigh impact
Deployments must consider in-flight instances created under older workflow definitions.
- Logic Apps and Durable Functions are natural choices when durable orchestration state and retries are part of the runtime model.
- BizTalk orchestrations are classic process-manager implementations and require careful preservation of correlation and compensation semantics during migration.
- Persist stable business identifiers so operators can find an instance independently of platform-generated run identifiers.
What this pattern helps you decide
Use a stateful coordinator that tracks process progress and determines the next action from business state, events and completion rules.
Which state must survive process restarts and long waits?
What detects and recovers a process that stops making progress?
Can in-flight instances survive a deployment or version transition safely?
Where you may see it
- Durable Functions orchestrator
- Logic Apps stateful workflow
- BizTalk orchestration
How the analyzers can surface it
- BizTalk orchestration services
- Stateful and branching flows
Pattern detection is contextual. GateSift should present these as architectural signals, not claim a pattern is implemented solely because one policy statement or adapter exists.
GateSift support
Where GateSift can surface this pattern
Detection means the source contains direct structural evidence. Signal means the analyzer sees compatible structure but still needs architectural context.
Source, licence and attribution
The pattern name and selected problem statement are adapted from Enterprise Integration Patterns by Gregor Hohpe and Bobby Woolf under CC BY 3.0. GateSift summaries, Azure mappings, analyzer guidance and diagrams are original. No endorsement by the original authors is implied.