1. Introduction
Purpose
Many processes in an organisation are sequences of steps: fetch a record, ask a person to approve it, update a system, send a message. Today each such process is either done by hand or written as a separate program. The workflow engine replaces both. A process is written once as a description of its steps, and the engine runs that description every time the process is needed.
The engine serves every team and every domain. Approval flows, onboarding, periodic reports, document processing, and reminders all use the same engine. Only the step contents differ.
Design principles
1. A workflow is data, not code. Each workflow is a JSON file that lists its steps in order and says how data moves between them. Adding a workflow means adding a file, not deploying a program.
2. One engine runs every workflow. The engine reads the JSON file and performs each step. It records the position of each run, so a run survives restarts, can wait for days, and retries failed steps.
3. Workers extend the engine's reach. The engine performs generic steps itself: call an API, branch, wait, call a model, wait for a person. Some steps need to run where the engine cannot: next to an on-premises system, with a credential the engine must not hold, or with logic that has no API. Workers cover those. A worker is a small service, maintained by the platform team, that implements one or more step types. It polls the engine for work, performs it, and reports back. Workflows use a worker step by naming its type, the same way they name an API. Likely examples in this organisation: document parsing (parse_pdf, extract_excel), long-running reconciliations over the data platform, and connections to systems that are only reachable from inside the network.
Platform services
The engine is built from Azure services. No third-party workflow product is installed. The main services are:
| Service | Role |
|---|---|
| Azure Functions | Runs the engine code |
| Durable Task Scheduler | Remembers where each run is |
| Azure SQL | Stores workflow definitions and run history |
| Service Bus | Holds work waiting for workers |
| API Management | Checks who is calling and what they may do |
| Azure Blob Storage | Stores large data and old runs |
| Foundry | Provides AI models |
Each service is explained where it first matters. The next page shows how they fit together.