BPMN Series #7 | ATL001
Common BPMN Modeling Mistakes: Basic Events
by Gregor Polancic
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):
Figure 1: BPMN Event
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).
As you can see from 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: time-based, messagebased, rule-based, signal-based, exceptionbased, etc.
•
An event can be positioned within
sequence flow or attached at the boundary
of an activity.
Figure 2: Full Set of BPMN Events
•
An event can interrupt current process
execution or not.
•
Some types of events can start a parallel,
event-based sub-process.
© Copyright 2014 Good e-Learning. All rights reserved. No part of this publication may be reproduced, resold, stored in a retrieval system, or distributed in any form or
by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of the copyright owner. Such requests for permission or any
other comments relating to the material contained in this document may be submitted to: marketing@goodelearning.com. Good e-Learning is a trading name used by
Educational Systems Ltd.
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:
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):
Figure 3: BPMN Event Symbol Syntax
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”.
Figure 6: Basic (descriptive) BPMN Events
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
Figure 4: The Context of Usage of an Equal BPMN Event
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):
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.
Figure 7: NOT RECOMMENDED. Implicit Process Events
Figure 5: Descriptive BPMN Events
© Copyright 2014 Good e-Learning. All rights reserved. No part of this publication may be reproduced, resold, stored in a retrieval system, or distributed in any form or
by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of the copyright owner. Such requests for permission or any
other comments relating to the material contained in this document may be submitted to: marketing@goodelearning.com. Good e-Learning is a trading name used by
Educational Systems Ltd.
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.
Figure 10: WRONG. Equally Named Process Events
Figure 8: RECOMMENDED. Explicit Process Events
Note 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 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.
Figure 9: INADEQUATE. Naming of an Event According
to its Type
Solution. 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. 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.
Figure 11: RIGHT. Uniquely Named Process Events
Mistake 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.
© Copyright 2014 Good e-Learning. All rights reserved. No part of this publication may be reproduced, resold, stored in a retrieval system, or distributed in any form or
by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of the copyright owner. Such requests for permission or any
other comments relating to the material contained in this document may be submitted to: marketing@goodelearning.com. Good e-Learning is a trading name used by
Educational Systems Ltd.
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).
Figure 12: UNLIKELY. Terminate End Event
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.
Conclusions
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.
Figure 13: FREQUENTLY. Generic End Event
© Copyright 2014 Good e-Learning. All rights reserved. No part of this publication may be reproduced, resold, stored in a retrieval system, or distributed in any form or
by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of the copyright owner. Such requests for permission or any
other comments relating to the material contained in this document may be submitted to: marketing@goodelearning.com. Good e-Learning is a trading name used by
Educational Systems Ltd.