BPMN 2.0 Workflows
Last updated 12 Oct 2026
At a glance
BPMN 2.0 lets orchestration logic live in visual process models that a workflow engine executes directly, instead of in SOM and ROM application code. The model an analyst reads is the model that runs. Changing a route, a timeout or a failure path becomes a model change.
The picture
One fixed-broadband fulfilment process, drawn with the BPMN 2.0 elements an O2A workflow uses
1 · Start
Service order received
start event · TMF641 from COM
2 · Route
Exclusive gateway: which technology?
fixed access → this path
mobile → mobile-core sub-process (not taken)
3 · Parallel work
Parallel gateway: run all three, join when all finish
service task
Assign and activate access
resource order to ROM · TMF652
error boundary → compensate: release port
user task
Field installation
engineer visit at the appointment
timer boundary → raise jeopardy, escalate
service task
Configure CPE
reusable sub-process, called by other flows
4 · Close
service task
Update service inventory
TMF638
Fulfilment complete
end event · TMF641 state event to COM
Thin circle = start event · thick circle = end event · diamond × = exclusive · diamond + = parallel · boundary events sit on a task’s edge
How it works
What BPMN 2.0 is
Business Process Model and Notation 2.0 is an OMG standard, also published as ISO/IEC 19510. BPMN 1.x was a drawing notation. BPMN 2.0 added an executable XML format, so engines such as Camunda, Flowable, Zeebe and jBPM run the definitions directly. In O2A, BPMN models the fulfilment workflow SOM or ROM runs for each order type.
In older architectures the same logic is hard-coded. Every change to a fulfilment flow needs a developer, a deployment and regression testing.
The elements that matter in O2A
| Element | Notation | O2A use |
|---|---|---|
| Start / end event | Thin / thick circle | Order received from COM; fulfilment complete |
| Service task | Rounded rectangle, gear | Automated step: call an activation API, update inventory |
| User task | Rounded rectangle, person | Manual step: exception review, field dispatch |
| Parallel gateway (AND) | Diamond with + | Fork and join independent work |
| Exclusive gateway (XOR) | Diamond with × | Route by technology: mobile to the core, fixed to access activation |
| Timer boundary event | Clock on a task edge | Escalate when a step exceeds its time |
| Error boundary event | Lightning on a task edge | Catch an activation failure and start compensation |
| Sub-process | Rectangle with + | A reusable block such as "Activate fixed line", called from several flows |
Why SOM is the main target
SOM has the most branching (by technology, by address, by order action), the most parallel work and the most exception handling. Those are exactly what gateways, boundary events and compensation express. ROM workflows are usually narrower and closer to device transactions.
When BPMN is the wrong tool
- Simple lifecycles such as COM order states suit a state machine better than a process model.
- Loosely coupled systems reacting to each other’s events suit choreography better than one central process.
- Rule-generated plans, where the catalog builds the plan per order, do not fit one fixed model per service type. Most estates combine both.
AI alongside BPMN
AI-augmented orchestration keeps the BPMN process as the record of sequence and exception handling, and uses models to improve decisions inside it: better inputs to gateways (which supplier or path), generated technical designs, a failure-risk score before commit, early warning of supplier delay, and analysis of activation test telemetry. Fulfilment still needs deterministic, auditable execution for regulation, SLAs and compensation, so the engine governs; AI informs the steps.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Process definition (BPMN model) | Workflow engine repository | Process modelling tool | — | Versioned. In-flight orders finish on the version they started on. |
| Process instance state | Workflow engine | — | SOM | Which step each order is on, timers and pending user tasks. |
| Service Order | SOM | — | Workflow engine | TMF641. The order state is SOM’s; the engine runs the steps behind it. |
| Manual work item (user task) | Workflow engine task list | Operations work queue | — | Must link back to the order item it holds up. |
In practice
The engine may come inside a SOM product or be a separate engine that an integrator builds on. Either way, the gains depend on discipline: small reusable sub-processes, catalog data driving gateways, and a process library that is versioned and tested like code.
Versioning has a runtime cost. Long-running orders (weeks for a field install) run on the model version they started with, so several versions stay live at once and fixes do not reach orders already in flight.
The trade-off
What it solves
It takes orchestration logic out of application code and puts it in a standard, executable model that analysts can read, change and version.
What it does not solve
- Poor catalog or inventory data feeding the gateways.
- The design of compensation. BPMN can express it, but someone must still decide what undo means for each step.
- Fallout caused upstream, which the engine routes but cannot prevent.
What it adds
- A workflow engine to run, scale and upgrade, plus its own data store.
- Model versioning with long-running instances on several versions at once.
- Testing process models as rigorously as code.
Architecture decision
How should fulfilment flows be expressed?
BPMN process per service type
Choose when flows branch heavily, have human tasks and timers, and must be auditable and readable by operations.
State machine
Choose when the lifecycle is simple and linear, as with commercial order states.
Catalog-generated plan executed by a generic engine
Choose when there are many service types built from shared RFS, and new types should be catalog changes rather than new models.
Breaks if Each product gets its own large BPMN model with routing hard-wired. The estate ends up with hundreds of near-duplicate models that are harder to change than the code they replaced.
Takeaways
Key Takeaways
- BPMN 2.0 models are executable: the diagram is the orchestration logic
- SOM is the main target because of its branching, parallelism and exception handling
- Boundary events and gateways express timeouts, failures and routing that code otherwise hides
- BPMN is not always right: state machines suit simple lifecycles, choreography suits loosely coupled systems
- AI improves decisions inside the workflow; the deterministic engine still governs execution
Check yourself
An activation step must escalate if it has not finished in four hours. Which BPMN element models that?Show answerHide
A timer boundary event on the activation task, leading to an escalation path such as a user task or a jeopardy notification.
Why would you not model the COM product order lifecycle in BPMN?Show answerHide
It is a simple, mostly linear set of states. A state machine expresses it more directly; a process engine adds runtime and versioning cost for little gain.
A team proposes replacing the fulfilment workflows with an AI agent that decides each step. What is the objection?Show answerHide
Fulfilment needs deterministic, auditable execution for regulation, SLAs and compensation. AI can improve gateway inputs and predict failures, but the workflow engine should still govern the sequence.