--- title: "Workflow orchestration: state, retries and recovery" description: "Workflow orchestration coordinates multi-step work across systems, people and AI while preserving state, policy, observability and recovery." canonical: "https://zephior.com/glossary/workflow-orchestration" last-updated: 2026-07-28 --- # Workflow orchestration: state, retries and recovery > Workflow orchestration coordinates multi-step work across systems, people and AI while preserving state, policy, observability and recovery. By [Tony Kim](https://zephior.com/authors/tony-kim). Published 2026-07-28; updated 2026-07-28. 5 minute read. ## Definition Workflow orchestration coordinates a sequence or graph of tasks across systems and actors while maintaining execution state. It decides when work starts, waits, retries, branches, requests approval, handles failure and records completion. ## Problem A chain of successful API calls is not a reliable business process. Services time out, messages arrive twice, people respond days later and partial writes leave conflicting state. AI steps add probabilistic output and variable latency. Without durable orchestration, recovery depends on logs and manual guesswork. ## Point of view Orchestration should make business state explicit. Model each material transition, make external writes idempotent, separate technical retry from business exception and preserve a human-readable record from trigger to reconciled outcome. ## Integration moves data; orchestration owns progress An integration connects systems and transforms messages. Orchestration coordinates several integrations and decisions toward one business outcome. It remembers that a case is waiting for evidence, that an approval expires tomorrow or that a target write succeeded before a later step failed. Simple synchronous operations may not need a workflow engine. Durable orchestration earns its complexity when work spans systems, time, retries, approvals or compensation. The design should reduce operational ambiguity, not introduce a hidden platform for every function call. | Concern | Weak implementation | Durable response | | --- | --- | --- | | State | Status scattered across services | Explicit workflow history | | Retry | Repeat the whole script | Task policy with idempotency | | Human wait | Polling or open thread | Durable task and deadline | | Partial failure | Manual log investigation | Compensation and resolution state | | Completion | Last function returned | Business outcome reconciled | ## Probabilistic steps need deterministic envelopes Record the model, prompt, context and validation version that produced an AI result. Validate structure and policy before the next effect. Store the accepted output as a workflow artifact so a retry after network failure does not silently generate a different business decision. Use risk-based review and explicit abstention paths. A low-confidence extraction can move to human correction; an unsupported proposal answer can return to evidence gathering. The orchestrator handles state and recovery, while the model handles the bounded language task. - Model business states explicitly. - Make all external writes idempotent. - Separate retry from exception handling. - Persist accepted AI output and provenance. - Reconcile completion with systems of record. ## Workflow 1. **Define business states and invariants.** Name the trigger, accepted inputs, material states, completion and failure outcomes. Define what must always be true, such as one approved payment per invoice. Avoid modelling only implementation steps; operators need states that explain business reality. 2. **Design task boundaries.** Give each task a clear input, output, timeout and owner. Isolate external effects from pure computation. Attach stable business and idempotency identifiers. Decide which errors are transient and which require corrected data, approval or a different path. 3. **Add waiting, review and compensation.** Represent timers, callbacks and human tasks as durable waits rather than blocked threads. Store the evidence shown at approval. For effects that cannot roll back, define a compensating action or manual resolution and make its consequence visible. 4. **Operate from end to end.** Expose current state, history, attempts, dependencies and next action. Alert on business deadlines and stuck work rather than every transient retry. Reconcile completed workflows with target systems and rehearse replay, cancellation and recovery under failure. ## Key decisions - Which states express business meaning rather than technical activity? - What identifier prevents a repeated task from duplicating an effect? - Which failure is retryable and which needs human or business action? - How is a partially completed process compensated or reconciled? - What evidence must remain with a later approval decision? ## Risks - Blind retries duplicate payments, messages or record changes. - Distributed status fields drift without one authoritative process state. - A human task can wait indefinitely without deadline and escalation. - Replaying a model step can produce a different result under the same business case. - Technical completion can be reported while the target system rejected the outcome. ## Metrics - end-to-end completion and business failure rate - workflow age and time in each state - retries and duplicate effects prevented - exceptions by technical and business cause - human wait and escalation time - reconciliation and compensation success ## Frequently asked questions ### What is workflow orchestration? It is the coordination of multi-step work across systems and people with explicit state, branching, waiting, retries, approvals, failure handling and completion records. ### How is orchestration different from automation? Automation performs a task. Orchestration coordinates several tasks, dependencies and actors toward an end-to-end outcome and manages what happens when work waits or fails. ### What is a durable workflow? A durable workflow persists execution history and state so long-running work can survive restarts, wait for external events and resume without losing progress or duplicating effects. ### How should AI steps be orchestrated? Bound the task, record versions and context, validate output, route uncertainty, persist the accepted result and place deterministic policy and authorization before external effects. ## Primary sources - [Business Process Model and Notation Version 2.0.2](https://www.omg.org/spec/BPMN/2.0.2/), Object Management Group - [AI Risk Management Framework Core](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/), National Institute of Standards and Technology