Design a process as a graph of nodes —tasks, decisions, integrations, waits— and Process Orchestrator executes it step by step, keeping full traceability and reacting to failures according to the rules you declare in the diagram itself.
Process Orchestrator turns them into executable, coordinated, auditable flows.
Work that today runs on email, Excel or one-off scripts, executed reliably and repeatably.
CRMs, ERPs and SaaS APIs orchestrated with no glue code in between.
A signature, a confirmed payment, an IoT event — the flow resumes on its own when it lands.
Every step is logged with who, when and why. Full traceability.
Automatic retries, exception connectors and TTL — without losing work.
From the design you draw in Studio to every concrete step the engine executes and records.
The process you draw: nodes, connectors, properties. No runtime state. Versioned and immutable once published.
One specific run of one version. It has context, state and timings. Thousands can run at once, independently.
The cursor that advances through the graph. It splits at a parallel fork and merges at a join. Its state rolls up into the instance's.
One node executed by one token, with inputs, outputs and timings. What you see in the viewer when you inspect an instance.
Our own model: simpler than BPMN 2.0, and far more explicit about errors and timing.
Kicks off the instance. Runs exactly once.
Human task. Creates an inbox entry and waits for someone to complete it.
External integration (HTTP/JDBC/FTP/SaaS). Delegates to the crawler.
Waits for a real-world event or for a set amount of time.
Decision, fork or join. Evaluates conditions and branches the token.
Runs an inline expression to transform context variables.
Iterates over a collection until it is exhausted.
Marks an end point and closes the token.
When something fails, the state is recorded and the engine looks for the recovery branch you declared. Nothing gets lost.
The default: followed when the node finishes successfully.
An unhandled exception or an ERROR state. The node is marked handled and the token carries on down this branch.
For action only: the maximum number of attempts was reached. Route it, for example, to a human review queue.
For wait and action: the node's TTL expired and the flow takes an alternate route.
Model it and the flow recovers on its own. Don't, and the token sits in error waiting for manual intervention — and an operator can always retry any node from Studio. A safety net (DLQ) catches whatever isn't even interpretable.
TTL isn't a timeout for killing long-running jobs: it's the way out of waits that drifted into limbo. On expiry, the engine cancels the in-flight work automatically.
expires_at = now + 120s is recorded.CANCELLED and stops retrying.expired branch if there is one; otherwise it lands in TTL_EXPIRED.// TTL counts wall-clock time; max_attempts counts attempts. They are independent and they combine.
Failure isolation, independent scaling and the right language for each problem. If the component calling an ERP goes down, the engine keeps going and the jobs are retried when it comes back.
Runs processes: receives events, moves tokens, picks branches and persists state.
Versioned definitions. Multi-tenant. Only the engine reads from here.
Runs external integrations (HTTP/JDBC/FTP) on demand from the engine.
Design processes, monitor instances and manage tasks, all in the browser.
Wakes tokens that are sleeping on time (waits like "wait 2 days").
Receives external webhooks and translates them into events for the engine.
Shared durable state. The system's source of truth lives here.
End-to-end delivery with idempotent handlers. Effectively exactly-once.
Only one version is active per process. Live instances keep running the version they started on — swapping the graph mid-flight would be a broken promise.
Standard authentication with swappable identity providers, plus per-organization isolation in the process repository.
Each organization sees only its own processes, folders and datasources. Isolation by organization_id.
Amazon Cognito or ZITADEL (self-hosted), depending on the environment.
Every state transition is logged with timings, attempts and errors.
Flows are designed in a visual editor, with no engine programming. Integration with a new system is modeled once, then reused everywhere.
Drag, connect and configure properties. Models the flow and its error branches without writing code.
100% visualDefines one YAML (Camel) connector per new external system. Once per system, not per process.
code-light · 1 YAML/systemExtends the engine through plugins (error policies, validation, observability) for advanced cases only.
code · rare casesWe'll walk you through Process Orchestrator with a real process from your business — and how Wattyo's consulting takes it to production.