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 are: “a telephone call”, “every 10 minutes”, “send message”, “service completed”, “an error occurred”, etc. A BPMN event is graphically represented with a circle (Figure 1):
- 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: time-based, message-based, rule-based, signal-based, exception-based, etc.
- An event can be positioned within sequence flow or attached at the boundary of an activity.
- An event can interrupt current process execution or not.
- Some types of events can start a parallel, event-based sub-process.
Most event type properties are evident from how they are graphically represented, for example in Figure 3, which describes a “non-interrupting intermediate catching message event” in the following ways:
However, despite its graphical representation, (Figure 3), 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 the context of its use:
- When used in a flow (between task 1 and task 2) the meaning of the event “10 minutes” is: “wait for 10 minutes before continuing to task 2”.
- When the event is attached to task 1, its meaning is: “after 10 minutes, task 1 is interrupted and the process flow continues to task 3”.
To make BPMN easier to learn and use, a descriptive set of BPMN elements exist which include only the following BPMN events (Figure 5):
Note that colors are not used in the BPMN specification. However, start events are commonly painted green (meaning “go”) and 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 the process in Figure 7. This modeling approach is undesirable and could lead to misinterpretations.
Solution. Use start and end events in each process and sub-process. By considering this, the start and end of a process (or sub-process) is more evident and might be additionally explained by process name or by specializing process events.
Mistake 2: Inadequate event naming
Problem. Modelers will commonly name start and end events according 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.
Mistake 3: Equal events
Problem. The BPMN specification allows the use of multiple start or end events at the same process level. Beware!. If several events share common naming and symbols, they actually represent a single event. Such a modeling approach might still be useful, since several equal events might reduce the number of process paths and path intersections, thus making it more easy to understand. However, it could lead to misinterpretations, as presented in the next figure.
The process in Figure 9 regularly 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), otherwise 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.
Problem. Modelers commonly over-use terminate end events instead of using simple end events, because they perceive a terminate end event as a “stronger” end of a process. This is partially true, but the devil is hidden in the detail! For example, the interpretation of the process, which is presented on Figure 13 is the following: The process first performs task 1 and then continues in both directions (parallel split), where 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 performing 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. Most commonly, a process modeler should use other 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.
BPMN is the most “event-rich” process modeling notation, supporting over 60 different types of events in total. This “diversity” can be use for precise process modeling. However it might also lead to misinterpretations; unfamiliar process symbols may also scare and confuse a novice. Whilst BPMN events are well organized in the specification, they are not quite as simple to learn as could be initially thought.
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.