ARCHITECTURE
A layered design for reliable workflow execution.
This is the conceptual system diagram for FLOWTYPE ORCHESTRATE. It explains how responsibilities are separated and is not documentation of a running system.
System diagram
Web App → API → Engine → Execution → Services → Data → Monitoring.
Layer 3 of 7
Workflow Engine
Owns workflow definitions: triggers, steps, conditions, approvals and versions.
- Definition model
- Validation before publish
- Version history
Describes intended structure for explanation. It is not documentation of a running system.
Design principles
What the architecture optimises for.
Separation of definition and execution
The workflow engine owns what a workflow is; the execution layer owns running it.
Failure as a first-class state
Retries, timeouts and error paths are part of the model, not afterthoughts.
Observable by default
Every step attempt is recorded and can be inspected.
Explicit branching
Conditions and approvals are visible transitions in the definition.
Bounded time
Every step has a timeout so runs cannot hang indefinitely.
Secure boundaries
Credentials are accessed through a controlled boundary, not embedded in workflows.
Execution lifecycle
How a run moves through the layers.
- 1A trigger reaches the API (webhook, schedule or API call).
- 2The workflow engine resolves the published definition.
- 3The execution layer queues the run and executes steps in order.
- 4Steps call connectors or AI services through the services layer.
- 5Records are written to the data layer at each step.
- 6Monitoring derives metrics and surfaces failures.
{
"execution_id": "demo_48291",
"workflow_version": 3,
"state": "success",
"steps": [
{ "id": "trigger", "state": "success", "attempts": 1 },
{ "id": "classify", "state": "success", "attempts": 1 },
{ "id": "crm", "state": "success", "attempts": 2 }
]
}BUILD YOUR FIRST WORKFLOW.
Turn repetitive business processes into reliable, observable workflows.