BPMN Diagram Example: An Order Fulfillment Process, Step by Step

BPMN (Business Process Model and Notation) looks like a flowchart with extra symbols, and that is how most people start using it. The extra symbols are the point: they let a diagram say who does each step, what starts the process, what runs in parallel and what crosses an organizational boundary, precisely enough that a developer and an operations manager read the same thing.

This guide builds one BPMN diagram step by step, an order fulfillment process for an online shop, and explains each element as it appears. At the end you will have a process you can adapt and a list of the mistakes that make BPMN diagrams hard to read.

The elements you need

BPMN 2.0 has a large vocabulary, but most process diagrams use a small core:

Element	Shape	Meaning
Pool	Large frame	One participant, such as a company or a customer
Lane	Row inside a pool	A role, team or system within that participant
Start event	Thin circle	What starts the process (a message, a timer, nothing in particular)
End event	Thick circle	A way the process can finish
Intermediate event	Double circle	Something that happens or is waited for along the way
Task	Rounded rectangle	One unit of work; a marker says if it is a user, service, send or manual task
Exclusive gateway	Diamond with X	Exactly one outgoing path is taken
Parallel gateway	Diamond with +	All outgoing paths run; a matching gateway waits for all of them
Sequence flow	Solid arrow	Order of steps inside one pool
Message flow	Dashed arrow	Communication between pools

The example: order fulfillment

The process, in plain words:

1. An order arrives from the customer.
2. The sales system checks stock.
3. If the item is out of stock, the customer is notified and the order is cancelled.
4. If it is in stock, payment is charged and the warehouse picks and packs the order, at the same time.
5. When both are done, shipping hands the parcel to the carrier.
6. The sales system emails the tracking link, and the process ends.

Here it is in BPMN:

Now let's build it piece by piece.

Step 1: Pools and lanes

Start with the participants. The shop is one pool with three lanes: Sales system, Warehouse and Shipping. The customer is a second pool, drawn collapsed as an empty band: we care about what they send and receive, not about how they decide.

Lanes answer "who does this?" without a single label on the tasks. If you cannot decide which lane a task belongs to, that is usually a real ownership question worth raising.

Step 2: Start and end events

The process starts when an order message arrives, so the start event gets a message marker. There are two ways to finish, so there are two end events: Order fulfilled and Order cancelled. Naming each end event after the outcome makes the diagram's results obvious at a glance.

Step 3: Tasks with verb and object

Name every task with a verb and an object: Check stock, Charge payment, Pick and pack, Ship order, Send tracking email. Add the task type when it helps: a service task runs without a person, a user task needs one, a send task sends a message. That one marker tells developers which steps they have to automate.

Step 4: Gateways for decisions and parallel work

The exclusive gateway after Check stock asks a question, In stock?, and its outgoing flows carry the answers, yes and no. Exactly one path is taken.

After the yes branch, a parallel gateway splits the flow: Charge payment and Pick and pack run at the same time. A second parallel gateway joins them, so shipping starts only when both are done. Splits and joins come in pairs; a parallel split without a join leaves tokens running through the rest of the process, which is almost never what you meant.

Step 5: Message flows between pools

Sequence flows stay inside a pool. Communication between pools uses message flows, drawn dashed: the order message into the start event, the out-of-stock notice and the tracking email back to the customer. BPMN does not allow a sequence flow to cross a pool boundary, and this rule forces you to show every handoff between organizations explicitly.

Extending the process

Real processes need more. A few common extensions and how BPMN expresses them:

• Payment fails. Wrap Charge payment and Pick and pack in a subprocess, attach an error boundary event to it, and route it to a task that returns the items to stock and notifies the customer. An error path out of just one parallel branch would leave the join waiting forever.
• Picking takes too long. Attach a non-interrupting timer boundary event to Pick and pack, for example 24 hours, and route it to an escalation task.
• The warehouse is a partner. Make it a separate pool and replace the sequence flows into it with message flows. The diagram then shows the contract between the two companies.

Add these only when the discussion needs them. A process diagram that tries to show every exception becomes a wall of arrows.

Common mistakes

• Sequence flows across pools. Use message flows between participants.
• Parallel paths merged without a join. Alternative paths may flow straight into the next task, but parallel paths must be joined with a parallel gateway, or the next task runs once per branch.
• Questions on the wrong element. Put the question on the gateway and the answers on its outgoing flows, not on the tasks.
• Vague task names. "Process order" hides five steps. If a task needs a paragraph, it is a subprocess.
• Everything in one lane. Without lanes, a BPMN diagram is a flowchart with fancier symbols.

BPMN or a flowchart?

Use a flowchart for quick logic, algorithms and how-to sequences. Use BPMN when ownership, waiting, parallel work or communication between participants matters, which is most business processes that involve more than one team. Archboard has both on the same canvas; see the flowchart use case and the cross-functional flowchart template for the simpler style.

Build it in Archboard

1. Sign in with Google or GitHub and create a diagram.
2. From the BPMN pack, add a Pool for the shop and give it three lanes, and a second, empty pool for the customer.
3. Add Start and End events, Task nodes with their task types, and Gateway nodes set to exclusive or parallel.
4. Connect the steps inside the pool, and draw dashed edges between the pools for message flows.
5. Label the gateway's outgoing flows with the answers, and add an Annotation for anything a reader needs to know.

The example uses 14 diagram nodes, within the Free plan. For related processes, see the payment flow diagram and value stream mapping use cases.

FAQ

Do I need to learn all of BPMN 2.0? No. Pools, lanes, start and end events, tasks, exclusive and parallel gateways, and message flows cover most diagrams. Add other symbols when a real case needs them.

Can a BPMN diagram be executed? Process engines can run BPMN models that include the technical details they need. A diagram drawn for people, like this one, is for agreeing on the process first.

How big should one diagram be? If it no longer fits on one screen, move a group of tasks into a subprocess and draw that separately.

Where do systems and data go? Use a lane for a system that does work, as with the sales system here, and data objects or data stores for information that tasks read and write.

How do I review a process diagram? Walk one real case through it, such as an out-of-stock order, with the people who do the work. Every place where they say "actually, we..." is a correction.

Start free — one seat, no credit card.