Workflow Design
Part of Stateful workflow orchestration
Choosing when a workflow needs to remember state
Use an interruption test to decide whether a workflow needs durable state and which progress it should retain.
A workflow must remember state when its next safe action depends on earlier progress that cannot be reliably recovered from the current event or business record. The practical test is interruption: if the worker stops now, can another worker continue without guessing or repeating a side effect?
Run the interruption test
Mark every action and wait in the process. At each boundary, note what a replacement worker needs. A queue consumer may handle one incoming event followed by one independently retryable update, if the destination can identify its outcome. A request that waits for approval then acts in several systems needs durable instance identity, a waiting stage and confirmed results.
| Process characteristic | What to consider |
|---|---|
| One immediate action with a checkable outcome | A queue consumer or ordinary service may suffice. |
| A person, callback or timer determines the next step | Persist the instance and its expected event or deadline. |
| Ordered actions span several services | Record which effects are confirmed and what remains. |
| A timeout leaves an outbound write uncertain | Provide a destination lookup or safe retry rule, with or without an orchestrator. |
Check the chosen runtime's documented wait duration, event-delivery behaviour and recovery limits before relying on it.
Specify the state needed to continue
Start with an instance ID, current stage, business-record reference and any deadline or downstream result ID needed for the next action. If a decision applies to a fixed record version, retain that version in the approval record. Avoid copying a whole business record into workflow state when a stable reference will do.
Define distinct transitions for decision received, external action requested and action confirmed. Rejection, expiry and manual review need their own outcomes. A single approved label is insufficient if it could mean a person decided or that a purchase order was created.
Keep progress separate from effects
A durable wait preserves the process's place. It does not make an external action safe to repeat. After a crash or timeout, the destination may have applied the first attempt even if the workflow did not record the response. Use a stable business reference to check the destination or a retry mechanism whose behaviour is documented for that destination.
A business field such as request.status = approved may tell you the decision but not whether a notification was sent or a downstream object was created. Persist orchestration state for those missing coordination facts. If the business application already exposes a complete, durable process state and recovery method, document how to use them before duplicating that state elsewhere.
For one representative request, identify the authoritative record, last confirmed effect and next permissible action at every interruption point. If those facts can be reconstructed consistently, record the reconstruction rule. Otherwise, persist the minimum state required to continue.
