Guide

Model your first BPMN process

In fifteen minutes you'll model a purchase approval process that is correct BPMN 2.0 — the kind of diagram you could hand to a developer or drop into a workflow engine. All you need is the free editor: no install, no account, and the file stays on your machine.

The process we'll model

An employee requests a purchase. Small purchases are approved automatically; anything else goes to a manager. Approved requests are ordered; rejected ones are returned with a reason. Plain enough to finish, real enough to matter.

Step 1 — start with the trigger

Every process starts because something happened. Open the editor and you'll see a start event (thin circle) already on the canvas. Click it, press E (or double-click), and name it Purchase requested. Naming events after the triggering fact — past tense — is a habit that pays off: readers instantly know what world state kicks things off.

Step 2 — add the first task

Click the start event once and use the context menu that appears next to it to append a task. Name it Submit purchase request. Use verb-object names for tasks — Check invoice, Approve request — never vague nouns like Processing. With the task selected, use the wrench icon to change its type to User task, since a person does this through a form.

Step 3 — the decision

Append a gateway (diamond) after the task and name it Amount?. A gateway's name should be the question being answered; each outgoing path is labeled with an answer. Append a task on one path: Approve automatically (a service task — the system does it). Then draw a second flow from the gateway down to a new user task, Manager reviews request.

• Label the first flow Small purchase and give it a condition in the properties panel.
• Right-click the second flow's source gateway and mark the manager path as the default flow — the safety net when no condition matches.

This condition-or-default discipline is exactly what the editor's validation checks. An exclusive gateway with unconditioned paths and no default is the most common defect in real-world BPMN — the diagram looks fine and then nobody can say which path a borderline request takes.

Step 4 — the second decision and the ends

After Manager reviews request, add another gateway: Approved?. The Yes path joins the automatic-approval path into a task Place order (service task), then an end event named Purchase ordered. The No path goes to Return request with reason (send task) and its own end event, Request rejected. Distinct end events per outcome make reports and conversations precise: "40% of instances ended in Request rejected" is a sentence a diagram with one generic end can't support.

Step 5 — validate, then save

Watch the validation counter in the toolbar as you work. Click it and the editor lists anything structurally wrong — an unconnected element, a missing condition, an unnamed gateway — in plain language, and clicking a finding centers the canvas on the offending element. When it reads clean, press Ctrl+S. The file saves as standard BPMN 2.0 XML on your disk: it will open identically in Camunda Modeler or any compliant tool.

Habits worth keeping

• Model left to right; time flows one way.
• Name every task (verb–object) and every decision gateway (a question).
• One start per trigger, one end per outcome.
• Let the happy path run straight; route exceptions downward.
• Use the process step list tool (Tools menu) to turn the finished diagram into numbered steps for a requirements document.

Next: browse seven real process templates to see these habits applied, or the symbol reference when you meet a shape you don't know. If you're wondering whether BPMN is worth it over a plain flowchart, that comparison is here.