Workflow orchestration definition
Workflow orchestration is the coordination of multiple automated tasks, systems, and human decisions into a single end-to-end process. It combines a definition that specifies the steps, their order, their dependencies, and the conditions for moving between them with a runtime that starts runs, evaluates those conditions, handles failures and retries, and records what happened.
Workflow orchestration coordinates many separate automated tasks and human steps into one governed process, run by a central coordinator rather than wired together by hand. In Sanity Workflows, currently in early access, a process is authored once as a definition and every run becomes its own document in the Content Lake, so "which articles published without legal review" is a GROQ query against content rather than a question someone asks in Slack.
Automation runs one task with little human involvement, while workflow orchestration coordinates many automated tasks toward a larger outcome. IBM puts it plainly: "Automation refers to the use of technology to complete a specific task with minimal human involvement. Orchestration takes a broader view, managing and coordinating multiple automated processes across systems." IBM calls orchestration the "automation of automation" and separates the two on four axes: business value (local savings versus a strategic outcome), complexity (static rules versus branching and exception handling), scope (a single task versus a complete process), and visibility (running quietly in the background versus dashboards and monitoring).
That last axis is the cleanest dividing line. A script that resizes an image is automation. A system that knows the image was resized, that the copy is still with legal, that the German translation has not started, and that nothing can publish until all three resolve is orchestration. Visibility is definitional, not a nice-to-have, because the whole point of a coordinator is that one place can answer where a process is and why it is stuck.
A useful test: if no single system can tell you the status of a running process, you have automation and integrations, not orchestration.
A workflow orchestration system has three parts. The first is a process definition: the steps, their order, their dependencies, the branching logic, and the conditions that allow a run to move from one step to the next. In data engineering this is often drawn as a DAG, a directed acyclic graph of jobs that cannot loop back on themselves. In business processes it is usually drawn as stages and transitions.
The second is a coordinating runtime, the component that starts a run against the definition, decides what happens next given what just happened, and recovers when a step fails. As the Zerve glossary describes it, a central orchestrator handles sequencing, retries, and error handling rather than leaving each job to fend for itself.
The third is
Orchestration has a central coordinator that holds the process and tells participants what happens next. Choreography has no coordinator: each service reacts to events that other services emit, and the process exists only as an emergent property of those reactions. AWS Prescriptive Guidance treats these as the two coordination approaches teams choose between when integrating services.
The tradeoff is real in both directions. Orchestration gives you one place to read the process and one place to see status, at the cost of a component every participant depends on. Choreography gives you looser coupling and no single bottleneck, at the cost of the process being written nowhere: to understand it, you read the event handlers of a dozen services and assemble the picture in your head.
Two related distinctions are worth keeping straight. A workflow is the process itself, a sequence of steps, while orchestration is the layer that runs workflows. A scheduler decides when something runs, as cron does, while an orchestrator decides what runs next given what just happened. Most orchestrators contain a scheduler; a scheduler on its own is not an orchestrator.
Workflow orchestration shows up in three overlapping places, and the term means something slightly different in each. In business process orchestration, it coordinates work like employee onboarding, payroll, order fulfillment, and supply chain handoffs across HR, finance, and logistics systems. In data orchestration, tools in the Airflow, Dagster, and Prefect lineage sequence extraction, transformation, and loading jobs so that a downstream job never runs on stale or missing upstream data. In AI and agent orchestration, the coordinator sequences model calls, tool invocations, and agents, increasingly with human checkpoints on the outputs that carry risk.
Content operations sits inside the first category and is the version most editorial teams run into. A single piece of content moves from brief to draft to review to legal approval to localization to publish to syndication, crossing several systems and several teams on the way. Each handoff is where the process stalls, because the status lives in whatever tool the last person happened to use.
The common failure mode across all three, in the systems we have worked on, is a pile of point-to-point webhooks standing in for a coordinator. Integration moves data between two systems; orchestration governs a process that may use many integrations as steps.
Sanity separates the automated step from the layer that coordinates steps, which matches the automation versus orchestration distinction. Functions, which are generally available, are serverless event handlers that run on Sanity's infrastructure, configured through Blueprints and triggered by document lifecycle events, Media Library asset changes, Live Content sync tag invalidation, a cron schedule, or a call from another function. Functions give you the individual automated tasks.
Sanity Workflows, currently in early access and built in public, is the coordination layer over them. You describe a process once as a definition, written in TypeScript with `defineWorkflow`, naming the stages content moves through, the work that happens in each stage, and the conditions for moving on. Every run produces an instance: a Sanity document holding its current stage, its open work, its queued effects, and a typed history array written in the same transaction as each state change. As the documentation puts it, "Status is a GROQ query, not a thread of messages."
Two design details matter for anyone evaluating an orchestrator. The engine is deterministic and never performs outside work itself: sending an email or triggering a build is queued as an effect into the instance, and a runtime you supply drains the queue and reports back, which puts failure and retries where they belong. And an instance pins the definition version it started under, so deploying version 4 leaves runs already in flight on version 3 untouched.
This is the Content Operating System for the AI era doing what a content operating system is for: people and agents move work through the same definition, and the record shows what automation produced and what a person changed. Workflows is pre-1.0, with every package on 0.x, where a breaking change bumps the minor version, so treat it accordingly when planning a rollout.
Discover More with Sanity
Now that you've learned about workflow orchestration, why not start exploring what Sanity has to offer? Dive into our platform and see how it can support your content needs.
Last updated: