What are Events?
An ‘event’ is a common BPMN process modeling element that represents something that “happens” during the course of a process. Examples of process events can include ‘a telephone call’, ‘every 10 minutes’, ‘send message’, ‘service completed’, ‘an error/ error event occurred’, etc.
In a BPMN diagram, a BPMN event is graphically represented with a circle (Figure 1):
Many different types of events can appear in a business process, and BPMN is capable of supporting most of them. In total, BPMN 2.0 supports more than 60 different types of events (Figure 2). There are also a number of applicable BPMN event subprocesses contained at process level.
As you can see from our sample BPMN diagram example in Figure 2, BPMN events are organized according to several criteria:
- An event can appear at the beginning of a process, within a process (intermediate), or at the end of a process
- An event can ‘catch a trigger’, which means that it reacts to something, or it can ‘throw a result’
- An event can be generic or one of several predefined types, including ‘time-based’, ‘message-based’, ‘rule-based’, ‘signal-based’, ‘exception-based’, etc.
- A BPMN event can be positioned within a sequence flow or attached at the boundary of an activity
- An event may or may not interrupt the current process execution
- Some types of events can start a parallel, event-based sub-process
Most event-type properties are quickly made evident by the way they are represented graphically. Figure 3, for example, describes a “non-interrupting intermediate catching message event” in the following ways:
However, even with a graphical representation, the meaning of an event can differ based on the context of its usage. As shown in the next figure, the same BPMN event (in this case an intermediate time event, ‘10 minutes’) can have different meanings based on how and where it is used:
- When used in a flow (between task 1 and task 2), the meaning of the event ‘10 minutes’ becomes ‘wait for 10 minutes before continuing to task 2’.
- When the event is attached to task 1, its meaning becomes: ‘after 10 minutes, task 1 is interrupted and the process flow continues to task 3’.
Descriptive BPMN Events
To make BPMN easier to learn and use, a descriptive set of BPMN elements exist which include only the following BPMN events (Figure 5):
The descriptive set consists of events that start (instantiate) a process and events that represent the final process state. Here is a bit more detail (Figure 6):
Note that colors are not used in the BPMN specification. However, start events are commonly painted green (meaning “go”), while end events are commonly painted red (meaning “stop”). Despite the limited set of descriptive events, there are several common mistakes that process modelers make.
Mistake 1: Implicit or Explicit Process Events
Problem. BPMN specification defines start and end events as optional. However, their usage is highly recommended, since each process starts and ends somewhere! Without explicitly using start and end events, a regular BPMN process might look at the process in Figure 7. This modeling approach is undesirable and could lead to misinterpretations.
Solution. Use start and end events for each process and subprocess. By using this approach, you can make the start and end of a process (or sub-process) more evident. You can take this further by using process names and specializing process events.
Note that if a process includes a start event, using an end event is mandatory.
Mistake 2: Inadequate Event Naming
Problem. Modelers will commonly name start and end events according to their role, e.g., ‘Process start’ or ‘Process end’. Since a start event symbol represents the process start and an end event symbol represents the process end, such naming is redundant.
Solution. Apply logic when naming events. If there is no specific event trigger or result, the naming of a generic event can be omitted.
Mistake 3: Equal Events
Problem. The BPMN specification allows the use of multiple start or end events at the same process level. But beware! If several events share common BPMN symbols and naming, they actually represent a SINGLE event.
Such a modeling approach can still be useful, since having several equal events might reduce the necessary number of process paths and path intersections, thus making diagrams easier to understand. However, it can also lead to misinterpretations, as presented in the next figure.
The process in Figure 9 includes two start and two end events. However, a detailed analysis of the process semantics shows that the naming of the process’s events is wrong. Since there are actually two different starts of a process and two different end states of the process, the respective events should be named uniquely (as presented in Figure 10), or someone could misinterpret the process model as having only one start event and one end event, which is wrong. A similar situation appears if a modeler does not name multiple start and end events.
Solution. If a process actually starts by different triggers or ends at different states, the names of the corresponding process events should be unique.
Mistake 4: End Event vs. Terminate Event
Problem. Modelers commonly over-use ‘terminate’ end events instead of using simple end events, the reason being that they perceive a ‘terminate’ end event as a stronger finish for a process. This is partially true, but the devil is hidden in the detail!
For example, the interpretation of the process presented on Figure 13 is the following: The process first performs Task 1 and then continues in both directions (parallel split), while Task 3 is performed several times on different data sets (Task 3 uses the multiple-instances marker ‘|||’).
The process is terminated when it reaches the ‘terminate’ end event. A terminate end event means that if one of the paths reaches an end, all other process paths (currently-active activities and activities which are waiting to be performed) are ended immediately. This could correspond to a real-life process situation, but it is very unlikely.
Most commonly, a process finishes successfully once all started process activities have finished, and a process will be terminated only if an unplanned event occurs (e.g., an exception).
Solution. A process modeler should use multiple end events (e.g., a generic end event), even if a process defines several end states (e.g., a successful and unsuccessful process end). When used this way, an end event will not stop the execution of the remaining process paths or activities.
Conclusions
BPMN is the most ‘event-rich’ process modeling notation in the world, supporting over 60 different event types in total. This diversity can be used for extremely precise process modeling. However, it can also lead to misinterpretations, and unfamiliar process symbols can even scare and confuse novices. Whilst BPMN events are well organized in the specification, they are not quite as simple to learn and apply in practice as some might think.
Whilst the descriptive level of BPMN elements reduces the set down to three start and end events, it does not include any intermediate events. This means that it is not possible to use events to manage descriptive process flows.
Interested in learning about BPMN? Visit Good e-Learning’s free online training library for more BPMN examples, or contact the GEL team today!
Are you interested in writing for Good e-Learning? We are currently accepting guest contributions and content exchanges in areas like ITSM, DevOps, and Cyber Resilience. Visit our Write for Us page to find out more, or contact a member of our team today!
