BPMN’s Most Undervalued Elements? Start and End Events

Have you learned BPMN in some class or with some book and your source simply told you – hey, it is good practice to place Start and End Events at the beginning and the end of your process model?

But do you know why and how you should place those elements? And how they can really help you in process workshops and when creating or reviewing process models? So, let’s start…

The BPMN Specification defines lots of event types – among them several start and end events. They are optional so you can either use no start and end events in your process model or every start and end have one event as shown in the following figure:

So far, so good, so easy. Most modeling guidelines require you to place those events. But why? In the example above the start and end events do not carry any information. And that is a problem. Modelers just place these events without thinking about what they should represent because they just learned to “place start and end events”.

What should we really do with them? Let’s look at an example with labels:

The start and end events form kind of a process contract. They define what triggers the process and what the result is. Thus, a start event defines the process trigger, and an end event defines the process outcome. They are thus an important part of the process documentation and therefore of the process model.

Another misconception is that there should be exactly one end event. While a single end event makes formal proofs in academia simpler, it should not be a rule to follow with real process models. Let’s have a look at the following process model:

This process model contains two end events: One denotes the outcome in the success case while the “goods not available” end state denotes some error state. A process model might contain as many of these error end states as necessary. Therefore, don’t hesitate to place as many end events as you need to denote all meaningful end states.

Sometimes, especially when moderating workshops or reviewing BPMN models, you can make easy findings when looking at the start and end events. I often come across models with something like that:

This model contains a labeled start event and a labeled end event. Also, the end event has a meaningful label. So on the first glance everything is fine. However, if you look closer the start event is that an invoice is received. The supplier is the customer of this process and there are expectations for the process end. Customers want their orders to be delivered (and the organization wants to be paid), and suppliers want their invoice to be paid. Consequently, the expected end event is likely “invoice paid”. The end event “invoice validated” is a strong hint that the modeled scope is only a subprocess. Thus, one should extend the scope of the process model or make it explicit that this is deliberately a subprocess.

Start and end events are valuable parts of BPMN process models. Modelers can express process triggers and successful and unsuccessful process outcomes thereby leading to better comprehensible models!