Comparison
BPMN vs. flowchart — when notation matters
Both are boxes and arrows. The difference is that a flowchart means whatever its author intended, while a BPMN diagram means what the specification says. That single property changes who can use the diagram and for what.
What a flowchart can't say
Draw "wait three days, then escalate" in a flowchart and you get a box labeled Wait 3 days. Nothing distinguishes it from a box of work; nothing says what happens to the waiting if the reply arrives on day two. In BPMN this is a timer boundary event on a task — a precise construct that says: while this task runs, a clock is armed; if it fires first, take this other path and (if interrupting) cancel the task. Everyone who reads BPMN reads that identically, and a workflow engine can execute it.
The gaps show up in predictable places:
- Who does what. Flowcharts have no standard for responsibility. BPMN pools and lanes carry it structurally, and every lane crossing is a visible handoff — which is where processes actually fail.
- Waiting vs. working. BPMN events distinguish "something happens" from "someone does something." Most real processes spend most of their life waiting; a notation that can't express waiting hides the dominant cost.
- Exceptions. A flowchart's happy path degenerates into arrow spaghetti the moment you add timeouts, errors, and cancellations. BPMN attaches those to the places they occur — boundary events, event subprocesses — keeping the main flow clean.
- Parallelism done right. A diamond that splits "and also" paths in a flowchart is ambiguous: do both run? must both finish? BPMN's exclusive, parallel, and inclusive gateways answer precisely, and validation can catch a parallel split merged by an exclusive join — a real defect that flowcharts cannot even express.
- A file format. BPMN 2.0 is XML with a standardized schema. Your diagram opens in this editor, in Camunda, in Signavio; it can be diffed, validated, and executed. A flowchart is a picture.
When a flowchart is the right choice
Honest answer: often. A five-box sketch of an idea on a whiteboard, a one-off explainer slide for an audience that will never see it again, an algorithm's control flow inside a single system — none of these need pools, events, or a schema. Notation has a reading cost, and BPMN's is only worth paying when the diagram will be used: handed across teams, kept current, analyzed, or automated.
The practical rule
| Situation | Use |
|---|---|
| Sketching an idea for yourself | Anything — paper wins |
| Explaining an algorithm inside one system | Flowchart |
| Documenting a business process with multiple roles | BPMN |
| Specifying behavior a team must build or follow | BPMN |
| Anything with deadlines, escalations, or messages between parties | BPMN |
| Anything a workflow engine might one day execute | BPMN, from day one |
The switching cost is lower than it looks: the core vocabulary is about a dozen shapes (reference here), and the tutorial gets you to a correct diagram in one sitting — in a free editor that validates as you draw.