BPMN Process Orchestration
Draw a network process as a BPMN flowchart and Versus executes it — parallel and conditional gateways, FEEL conditions, human approval tasks, DMN decisions, incident recovery, and process analytics. A full process-orchestration engine, native to network automation, that speaks standard BPMN 2.0.
Versus workflows have always run steps in sequence. BPMN Process Orchestration adds a real process engine underneath the Workflow Builder: you draw a process as a BPMN flowchart — a start, tasks, decision gateways, waits, and an end — and Versus executes that diagram with true process semantics. Branches run in parallel, a join waits for all of them, conditions route on live process data, people approve steps in a task inbox, decision tables classify inputs, failures become retryable incidents, and every run feeds process analytics.
It is the orchestration model that Camunda, Zeebe, and jBPM made standard — brought into Versus, kept network-native, and made to round-trip with standard BPMN 2.0 XML so existing models import directly.
Why it matters
A serial script does one thing at a time and fails all-or-nothing. A real network change is not serial: you upgrade three datacenters at once, wait for all of them, decide what to do next based on their health, pause for a human to approve the production cutover, and roll back cleanly if anything goes wrong. That is a process, and expressing it as one turns a brittle, opaque script into a visible, parallel, health-gated, human-in-the-loop workflow.
The example above — Multi-DC F5 Upgrade — is exactly that process. It is a single workflow that:
- opens a change (ServiceNow),
- forks and upgrades F5 BIG-IP in DC-A, DC-B and DC-C concurrently (a parallel gateway),
- joins — waits for all three to finish,
- evaluates a health gate (an exclusive gateway with a FEEL condition),
- on healthy: pauses at Approve prod cutover (a human task) → flips GTM → done,
- on unhealthy: routes to compensate / rollback.
Turning it on
Process orchestration is opt-in per workflow and off by default, so every existing workflow keeps running exactly as before. In the Workflow Editor, toggle BPMN on (it sets the workflow's execution mode); a run then executes on the token engine instead of the legacy single-cursor walk.
Gateways — the control flow
Gateways are the diamonds in the diagram. Drag them from the BPMN Gateways palette. Each carries a BPMN symbol and a single connection point; draw as many outgoing flows as you need.
| Gateway | Symbol | Behavior |
|---|---|---|
| Parallel | + | Fork a token down every outgoing flow; the matching join waits for all branches before continuing. Use it to do things at once — upgrade every datacenter simultaneously. |
| Exclusive | × | Take the first outgoing flow whose condition is true, else the default flow. Classic either/or routing — the health gate. |
| Inclusive | ○ | Fork every flow whose condition is true (one, several, or all); the join waits for exactly the branches that activated. |
The engine is token-based: a run holds one or more tokens, each sitting on an element. A parallel fork creates a token per branch and the join consumes them once all have arrived — the same execution model as a dedicated BPMN engine, running on Versus's existing executor so the debugger, validation, and SDK all keep working.
FEEL conditions
Every gateway flow can carry a FEEL condition — the OMG expression language used by BPMN and DMN. Click a connection to open its editor and type a condition over the run's variables:
health.failed_count = 0 and health.min_version >= 17.1
FEEL in Versus supports comparisons (=, !=, <, <=, >, >=), boolean logic
(and / or / not), membership (x in ["high", "critical"]), ranges, and helper functions
(contains, starts_with, count, min, max, …). It is sandboxed — a real parser, never
arbitrary code — so a condition can read process data but can never run commands. Tasks feed the
conditions: whatever a step sets with versus.set_output(...) becomes a variable the downstream
gateways evaluate. Errors are reported by the Validate button before you ever run.
Connections that follow the work
Connections are floating edges: each attaches at the point on a node's border nearest the other
node, and re-routes live as you drag — so a join always takes the shortest path and the diagram
stays readable as it grows. Conditional flows show their FEEL condition (or default) as a label.
What's in the box
Process orchestration is a family of capabilities. Each has its own guide:
- Human Tasks & the Tasklist — user tasks with assignment, candidate groups, due dates and a claim/complete inbox.
- DMN Decision Tables — reusable business rules with hit policies, callable from a workflow or as a decision-as-a-service API.
- The Operate Console — running instances, incidents with one-click retry/resolve, and batch operations.
- Optimize — Process Analytics — duration, bottleneck, and throughput analytics computed from real run history.
Standard BPMN 2.0 — import & export
Versus round-trips with BPMN 2.0 XML. Export BPMN in the editor downloads a workflow as a
standards-compliant .bpmn file; Import BPMN on the Workflows list turns a BPMN file from Camunda,
Zeebe, or Signavio into a runnable Versus workflow — gateways, sequence flows, conditions, and all.
Your existing process models are not locked into another vendor.
How it stays safe
Everything here is additive and inert by default. BPMN mode is opt-in per workflow; the legacy executor runs untouched for every existing workflow; and each capability ships behind its own flag. There is no migration and no regression — you adopt process orchestration one workflow at a time.
See also the platform comparison — how Versus's process orchestration lines up against Camunda, Temporal, Ansible, and Pega.