BPMN Basic Events

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):

diagram-1Many 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).

diagram-2As you can see from Figure 2, BPMN events are organized according to several criteria:

  1. An event can appear at the beginning of a process, within a process (intermediate) or at the end of a process
  2. An event can “catch a trigger”, which means that it reacts to something or it can “throw a result”
  3. An event can be generic or one of several predefined types: time-based, message-based, rule-based, signal-based, exception-based, etc.
  4. An event can be positioned within sequence flow or attached at the boundary of an activity.
  5. An event can interrupt the current process execution or not.
  6. 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:

diagram-3However, 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”.

diagram-4Descriptive 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):

diagram-5The 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):

diagram-6Note 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 at the process in Figure 7. This modeling approach is undesirable and could lead to misinterpretations.

diagram-7Solution. Use start and end events in each process and subprocess. 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.

diagram-8Note that if a process includes a start event, 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.

diagram-9Solution. Apply logic when naming events. In this case, because 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 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.

diagram-10The 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), 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.

diagram-11Mistake 4: End Event vs. Terminate Event

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).

diagram-12Solution. 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 used 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.

Interested in learning about BPMN? Visit Good e-Learning’s free online training library for more BPMN examples, or contact the GEL team today!

How to Start with BPMN Modeling
Gregor received his PhD in 2008 in the fields of software engineering and information systems and has nearly a decade of experience in BPMN, starting to investigate and actively use BPMN since its introduction in 2004. In addition, he has participated in the development of one of the first BPMN modeling utilities - a package of plugins for Visio, which were introduced early in 2005 and is the main author of the first BPMN poster (bpmn.itposter.net), which has been translated into several languages and already exceeded 50.000 downloads.