BPMN vs UML activity diagram

Start with what is not in dispute. Both notations describe a token travelling along a flow: it leaves a start, passes through pieces of work, splits at a branch, waits at a join and eventually stops. That model is inherited from the same place in both cases, and it is why the two diagrams of a simple approval process are recognisably the same drawing with different furniture.

If your process is a straight line with two decisions in it, the comparison stops here and you should draw whichever one your readers already know. The differences below only start to bite once participants, interruptions or automation enter the picture - which, admittedly, is most real processes.

1. The pool is a rule, not a label. This is the difference that matters most and is noticed least. A UML activity partition says who performs an action and nothing more, so control flow crosses partition boundaries as freely as it crosses anything else. A BPMN pool is a whole separate participant with its own process, and BPMN forbids sequence flow from crossing it: interaction between pools has to be a message flow. That single rule is why a BPMN diagram of two organisations is a statement about their independence, while the UML equivalent is a statement about staffing.

2. Interruption is first class in BPMN. Attach a boundary event to a task and you have said, in one mark, that this work can be cut short by a timer, an error or an incoming message - and whether the original path continues afterwards. UML can express the same thing with an interruptible activity region and an accepting event action, but the construct is rarely taught, rarely drawn and rarely read correctly. In practice, if the process is full of escalations and timeouts, BPMN will draw it in a third of the ink. The event vocabulary is most of what you are buying.

3. UML sits inside a larger model. An activity diagram shares its model with the class diagram beside it, so an action can consume an object of a type that is defined elsewhere and a tool can check that the type exists. BPMN has data objects, but they are process-local by design and carry nothing like a class model behind them. If the process description has to line up with a system design, that shared vocabulary is worth more than any notation feature.

4. Only BPMN is executable. BPMN 2.0 defines an XML serialization that workflow engines consume directly, which is why the same file can be a picture for the business and a deployment artefact for engineering. UML has fUML, an executable subset with defined semantics, and almost no engine that takes it. Treat this as the one hard constraint on the list: if there is an engine at the end of the pipeline, the notation is BPMN and the rest of this article is background.

The decision is nearly always made by the reader rather than by the process. Both notations can express any process you are likely to draw; only one of them will be read on sight by the people who have to approve it.

Where the reader is genuinely mixed - and on a project of any size they usually are - draw the process once in BPMN for the people who own it, and keep the activity diagram for the parts of the flow that are really algorithm rather than process. That split follows the audience instead of fighting it, and it is much easier to defend in review than a single diagram that half the room cannot read.

Conversions in either direction are routine, and the honest way to do one is to decide in advance what you are willing to lose. Going from BPMN to UML, the control flow transfers almost perfectly: tasks become actions, exclusive gateways become decision and merge nodes, parallel gateways become forks and joins, and the gateway rules map one for one. Everything about participants and events is what you give up.

Going the other way, the losses are smaller but the additions are work: BPMN will want a start event, an end event and a pool for every actor you had modelled as a partition, and it will refuse to let sequence flow cross those pools. That refusal is usually where the exercise pays for itself, because it forces a question the activity diagram let you avoid - are these one process or two?

Whichever direction you go, the redraw is the expensive part, and it is the part a model-backed tool removes: keep the participants and the work as model elements and the second view stops being a second drawing. If you want to see the difference rather than read about it, the BPMN starter template opens a pool-and-lane process with the events already in place, and the fifteen-second demo hands back a real file at the end of it.