Skip to main content
Version: 8.5

BPMN primer

Business Process Model and Notation 2.0 (BPMN) is an industry standard for process modeling and execution. A BPMN process is an XML document that has a visual representation. For example, here is a BPMN process:


The corresponding XML

<?xml version="1.0" encoding="UTF-8"?>
<bpmn:definitions xmlns:bpmn="" xmlns:bpmndi="" xmlns:di="" xmlns:dc="" xmlns:xsi="" xmlns:zeebe="" id="Definitions_1" targetNamespace="" exporter="Camunda Modeler" exporterVersion="0.1.0">
<bpmn:process id="Process_1" isExecutable="true">
<bpmn:startEvent id="StartEvent_1" name="Order Placed">
<bpmn:sequenceFlow id="SequenceFlow_1bq1azi" sourceRef="StartEvent_1" targetRef="Task_1f47b9v" />
<bpmn:sequenceFlow id="SequenceFlow_09hqjpg" sourceRef="Task_1f47b9v" targetRef="Task_1109y9g" />
<bpmn:sequenceFlow id="SequenceFlow_1ea1mpb" sourceRef="Task_1109y9g" targetRef="Task_00moy91" />
<bpmn:endEvent id="EndEvent_0a27csw" name="Order Delivered">
<bpmn:sequenceFlow id="SequenceFlow_0ojoaqz" sourceRef="Task_00moy91" targetRef="EndEvent_0a27csw" />
<bpmn:serviceTask id="Task_1f47b9v" name="Collect Money">
<zeebe:taskDefinition type="collect-money" retries="3" />
<bpmn:serviceTask id="Task_1109y9g" name="Fetch Items">
<zeebe:taskDefinition type="fetch-items" retries="3" />
<bpmn:serviceTask id="Task_00moy91" name="Ship Parcel">
<zeebe:taskDefinition type="ship-parcel" retries="3" />
<bpmndi:BPMNDiagram id="BPMNDiagram_1">
<bpmndi:BPMNPlane id="BPMNPlane_1" bpmnElement="Process_1">
<bpmndi:BPMNShape id="_BPMNShape_StartEvent_2" bpmnElement="StartEvent_1">
<dc:Bounds x="191" y="102" width="36" height="36" />
<dc:Bounds x="175" y="138" width="68" height="12" />
<bpmndi:BPMNEdge id="SequenceFlow_1bq1azi_di" bpmnElement="SequenceFlow_1bq1azi">
<di:waypoint xsi:type="dc:Point" x="227" y="120" />
<di:waypoint xsi:type="dc:Point" x="280" y="120" />
<dc:Bounds x="253.5" y="99" width="0" height="12" />
<bpmndi:BPMNEdge id="SequenceFlow_09hqjpg_di" bpmnElement="SequenceFlow_09hqjpg">
<di:waypoint xsi:type="dc:Point" x="380" y="120" />
<di:waypoint xsi:type="dc:Point" x="440" y="120" />
<dc:Bounds x="410" y="99" width="0" height="12" />
<bpmndi:BPMNEdge id="SequenceFlow_1ea1mpb_di" bpmnElement="SequenceFlow_1ea1mpb">
<di:waypoint xsi:type="dc:Point" x="540" y="120" />
<di:waypoint xsi:type="dc:Point" x="596" y="120" />
<dc:Bounds x="568" y="99" width="0" height="12" />
<bpmndi:BPMNShape id="EndEvent_0a27csw_di" bpmnElement="EndEvent_0a27csw">
<dc:Bounds x="756" y="102" width="36" height="36" />
<dc:Bounds x="734" y="142" width="81" height="12" />
<bpmndi:BPMNEdge id="SequenceFlow_0ojoaqz_di" bpmnElement="SequenceFlow_0ojoaqz">
<di:waypoint xsi:type="dc:Point" x="696" y="120" />
<di:waypoint xsi:type="dc:Point" x="756" y="120" />
<dc:Bounds x="726" y="99" width="0" height="12" />
<bpmndi:BPMNShape id="ServiceTask_0lao700_di" bpmnElement="Task_1f47b9v">
<dc:Bounds x="280" y="80" width="100" height="80" />
<bpmndi:BPMNShape id="ServiceTask_0eetpqx_di" bpmnElement="Task_1109y9g">
<dc:Bounds x="440" y="80" width="100" height="80" />
<bpmndi:BPMNShape id="ServiceTask_09won99_di" bpmnElement="Task_00moy91">
<dc:Bounds x="596" y="80" width="100" height="80" />

This duality makes BPMN very powerful. The XML document contains all the necessary information to be interpreted by workflow engines and modeling tools like Zeebe. At the same time, the visual representation contains just enough information to be quickly understood by humans, even when they are non-technical people. The BPMN model is source code and documentation in one artifact.

The following is an introduction to BPMN 2.0, its elements, and their execution semantics. It tries to briefly provide an intuitive understanding of BPMN's power, but does not cover the entire feature set. For more exhaustive BPMN resources, refer to the reference links at the end of this section.

Modeling BPMN diagrams

The best tool for modeling BPMN diagrams for Zeebe is Modeler.


BPMN elements

Sequence flow: Controlling the flow of execution

A core concept of BPMN is a sequence flow that defines the order in which steps in the process happen. In BPMN's visual representation, a sequence flow is an arrow connecting two elements. The direction of the arrow indicates their order of execution.

sequence flow

You can think of process execution as tokens running through the process model. When a process is started, a token is created at the beginning of the model and advances with every completed step. When the token reaches the end of the process, it is consumed and the process instance ends. Zeebe's task is to drive the token and to make sure the job workers are invoked whenever necessary.

Tasks: Units of work

The basic elements of BPMN processes are tasks; these are atomic units of work composed to create a meaningful result. Whenever a token reaches a task, the token stops and Zeebe creates a job and notifies a registered worker to perform work. When that handler signals completion, the token continues on the outgoing sequence flow.

Choosing the granularity of a task is up to the person modeling the process. For example, the activity of processing an order can be modeled as a single Process Order task, or as three individual tasks Collect Money, Fetch Items, Ship Parcel. If you use Zeebe to orchestrate microservices, one task can represent one microservice invocation.

Refer to the tasks section on which types of tasks are currently supported and how to use them.

Gateways: Steering flow

Gateways are elements that route tokens in more complex patterns than plain sequence flow.

BPMN's exclusive gateway chooses one sequence flow out of many based on data:

BPMN's parallel gateway generates new tokens by activating multiple sequence flows in parallel:

Refer to the gateways section on which types of gateways are currently supported and how to use them.

Events: Waiting for something to happen

Events in BPMN represent things that happen. A process can react to events (catching event) as well as emit events (throwing event). For example:

The circle with the envelope symbol is a catching message event. It makes the token continue as soon as a message is received. The XML representation of the process contains the criteria for which kind of message triggers continuation.

Events can be added to the process in various ways. Not only can they be used to make a token wait at a certain point, but also for interrupting a token's progress.

Refer to the events section on which types of events are currently supported and how to use them.

Subprocesses: Grouping elements

Subprocesses are element containers that allow defining common functionality. For example, we can attach an event to a subprocess's border:


When the event is triggered, the subprocess is interrupted, regardless which of its elements is currently active.

Refer to the subprocesses section on which types of subprocesses are currently supported and how to use them.

Additional resources