WEEK 3

SESSION 6

BUSINESS PROCESS
MODEL AND
NOTATION (BPMN 2)
- Part 2 -

BCO5501
BUSINESS PROCESS ENGINEERING

Updated: 4 September 2020

Copyright Notice
• The images used in these notes/papers have been reproduced either under Part VB of
the Copyright Act 1968 for educational purposes only, or under the terms of other sections of
the Act, or with permission of the copyright owner.​
• Please note that the Copyright for each work in the materials is owned by the author/s and/or
the publications listed.

Source: These slides are based on the following book:

• Bruce Silver (2011): BPMN Method & Style, with BPMN

Implementer’s Guide. 2nd Edition and August-Wilhelm Scheer, Henrik von Scheel, and Mark
von Rosing (2014), The Complete Business Process Handbook: Body of Knowledge from
Process Modelling to BPM, Volume 1

2
Acknowledgement of Country

We acknowledge the Ancestors, Elders and families of the Kulin Nation and Eora Nation
who are the Traditional Owners of University land. We also acknowledge all Traditional
Owners of Country throughout Victoria and NSW and pay our respect to their culture, and
their Elders past, present and future.

As we share our own knowledge practices within the University may we pay respect to the
deep knowledge embedded within the Aboriginal community and their ownership of Country.

We acknowledge that the land on which we meet is a place of age old ceremonies of
celebration, initiation and renewal and that the Kulin people’s living culture has a unique role
in the life of this region.

3
BPMN Levels and Process Modelling
Conformance Subclasses
◆ BPMN Level 1 palette composed of a limited working set of shapes and
symbols carried over from traditional flowcharting
◆ Sufficient for describing most process behaviour in a compact business-
friendly way
◆ In the spec, Level 1 is called Descriptive Process Modelling Conformance
Subclass
◆ BPMN Level 2 palette slightly larger to include exception handling, with
emphasis on Message, Timer, and Error events, plus some additional
branching and merging patterns
◆ Since event-triggered behaviour is a fact of life in real-world processes,
business analysts who want to use BPMN for defining solution requirements
need to learn this level
◆ Level 2 palette still has only about half of the full BPMN 2.0 working set, but
some tools don’t support all of it
◆ In the spec, Level 2 is called Analytic Process Modelling Conformance
Subclass

4
BPMN Levels and Process Modelling
Conformance Subclasses
◆ BPMN Level 3 refers to Executable BPMN
◆ Both Level 1 and Level 2 concern non-executable processes and rely solely
on information visible in the diagram.
◆ Executable BPMN, in contrast, is all about the XML details that are not
displayed in the diagram
◆ E.g. data models, detailed task assignment logic, conditional data expressions
at gateways
◆ In the spec, this is called the Common Executable Process Modelling
Conformance Subclass

◆ For non-executable process models, it’s the notation – what you see in
the diagram – that really matters
◆ If it’s not in the diagram it doesn’t count

5
6
Order Process, Top-Level Diagram
◆ Let’s take another look at our top-level Order process diagram.
◆ The details of Fulfill order are hidden, but we can drill down to see the child-level expansion
in a separate hyperlinked diagram.
◆ Note how much the top-level diagram reveals about this process.
◆ We see that the instance represents an order, since it starts upon receipt of the Order
message.
◆ It has two end states, Order complete and Order failed.
◆ The source of order failure is either
bad credit or out of stock with non-
acceptance of the offered replace-
ment.
◆ Each end state returns a different
final status message to the
Customer.
◆ With processes initiated by a
request message, it is good
practice to return final status to the
requester from message end events.
◆ It is a simple process, but not too
different from the top-level diagram of
typical real-world end-to-end processes.

7
The Level 1 Palette
◆ All of the shapes and symbols used so far are part of the Level 1 palette
◆ Called Descriptive Process Modelling Conformance subclass in BPMN 2.0

◆ If you are willing to ignore event-triggered behaviour, you can model almost
any process with the Level 1 palette.
◆ With the exception of message flows and Message events, the Level 1 notation is
basically carried over from traditional flowcharting.
◆ Complete list of the members of the Descriptive subclass in BPMN 2.0:
◆ Activity: Task (User, Service, None), Subprocess, Call Activity
◆ Gateway: Exclusive, Parallel
◆ Start event: None, Message, Timer
◆ End event: None, Message, Timer
◆ Sequence flow and Message flow
◆ Pool and Lane
◆ Data object, Data store, and Data association
◆ Documentation
◆ Artifact: Text annotation, Association, and Group

8
Step 1: Determine Process Scope
◆ Scenario: Let’s go through a car dealer’s order-to-cash process

◆ Top-down modelling starts with agreeing on the scope of the process, where it starts
and ends.
◆ The process does not have to be customer-facing, what we sometimes call end-to-end.
◆ There needs to be agreement on the scope before modelling begins.
◆ Key questions:
1. How does the process start?
◆ E.g., is it on request, either from an external entity or an internal task performer; or is it
regularly scheduled?
◆ Here: It starts with an order, an agreement from a particular buyer to buy a particular car for
an agreed price.
2. What determines when it is complete?
◆ Here: the process is not complete until the full amount of the purchase is paid and the buyer
receives the car.
3. What does each instance of the process represent?
◆ An instance of this process is a single order. What if the buyer purchase two cars?

4. Does the process have more than one end state?

◆ Successful closing of the transaction; financing unavailable; delivery date unacceptable.

9
Step 2: The High-Level Map
◆ High-level map activities in our example scenario:
◆ Finalise order
◆ Performed by Sales department; end states: Reserved from stock; Dealer trade; Order from factory.
◆ Acquire car from local dealer
◆ Conditional (not performed in all process instances); performed by Sales department; end state: Car
received.
◆ Acquire car from factory
◆ If the factory delivery date is later than the one estimated at the time of Finalise Order, the customer can
cancel the transaction.
◆ Conditional; performed by Sales; end states: Car received; Order cancelled.
◆ Prepare car for delivery
◆ Performed by Service department; end state: Ready.
◆ Arrange financing
◆ Can run in parallel with acquiring and preparing the car.
◆ Performed by Finance department; end states: Financing confirmed; Financing unavailable.
◆ Close and deliver
◆ May not start until both Arrange financing and Prepare car for delivery are complete.
◆ Performed by Finance department; end state: Transaction complete.
◆ Handle order cancellation
◆ Only performed when the order is cancelled before the closing.
◆ Performed by Finance department; end states: Delivery date unacceptable; Financing unavailable.

10
Step 3: Top-Level Process Diagram
◆ Now we can turn the high-level map into a top-level BPMN diagram.
◆ The process starts on request from the customer: Message start event
Receive order.
◆ Each high-level map activity becomes a subprocess in the diagram.

◆ We’ll start by considering only the “happy path” of the process and then add
the exception paths.
◆ It is often better to omit lanes in the top-level diagram and just put them in the
child-level diagrams.

11
Step 4: Child-Level Expansion
◆ The top-level diagram tells you how the process starts and ends, but it
reveals little about the internal details.
◆ For that you need to show the child-level expansion of each top-level activity.

◆ The child-level expansion must have a None start event.

◆ If you draw a pool, it must be named the same as the pool of the parent level,
i.e. the name of the process.
◆ You may include lanes; they are defined independently at each process level.

◆ Remember to create a separate end event for each end state of the high-
level map activity identified in Step 2, and label it with the name
of the end state.
◆ Here, we illustrate the first activity,
Finalise order, only.

12
Step 5: Add Message Flows

◆ Message flows show how your process interacts with the customer,
service providers, and other internal processes.
◆ They provide valuable business context for the process.

◆ Downside: the add visual clutter.

◆ Message flows always connect to either an activity or a Message event in the

process.
◆ Usually the other end of the message flow is connected to the boundary of a
black-box pool.
◆ Message flows indicate the possibility of a message; their order of
occurrence is ambiguous.
◆ Message flows should be consistent between parent and child levels.
◆ All message flows in the entire process model should be present in the top-
level diagram.

13
Step 5: Add Message Flows

Top-level diagram,
with message flows

14
Step 5: Add Message Flows

Order car from factory, child level, with message flows

15
The Level 2 Palette

◆ The most significant change between BPMN Level 1 and Level 2

is the emphasis on events.
◆ A BPMN event describes
◆ How the process responds to a signal (trigger) that something happened
(catching events), or
◆ How the process generates a signal (result) that something happened
(throwing events).
◆ At Level 1, each step in the process is triggered by the completion of the
prior step.
◆ Events let you describe additional behaviour
◆ E.g., the process pauses until the trigger occurs, and then resumes;
◆ If the trigger occurs while an activity is running, the activity is terminated
immediately and some other exception activity is initiated immediately;
◆ Or, alternatively, the activity continues but something else is initiated in
parallel with it.

16
Events
◆ BPMN provides a visual language for
all these event-triggered behaviours.
◆ “Bewildering array of event types”
◆ Table with 13 rows, one for each
trigger/result type, and 8 columns, a
total of 104 distinct combinations (half
of which are combinations that are not
allowed).
◆ But: No need to memorise them all!
◆ We will focus on the “Big 3” event types
– Timer, Message and Error

17
Events
◆ Level 1:
◆ None, Message and Timer start events
and None, Message and Terminate end
events (plus Multiple start and end
events)
◆ Level 2:
◆ Adds intermediate events (double ring)
plus a few additional triggers
◆ Error, Escalation, Conditional, Signal
and Link
◆ Timer, Message and Error are the ones
you really need to know.
◆ See green highlighting

18
Intermediate Events Catching and throwing Message event

◆ Event-triggered behaviour refers to process actions initiated immediately

upon occurrence of a specific trigger signal.
◆ Intermediate events (depicted wit a double ring) occur after the start of a
process level and before the end.
◆ Precise meaning depends on the details of its representation
◆ A throwing intermediate event (black icon inside) means the process generates
the trigger signal.
◆ Throwing the signal occurs immediately and automatically as soon as the incoming
sequence flow arrives, and the process continues immediately afterwards on the
sequence flow out of the throwing event.
◆ A Message intermediate event supports throwing behaviour, but not Timer or Error.
◆ A catching intermediate event (white icon inside) means the process waits for the
trigger signal.
◆ When the trigger signal arrives, the process resumes on the sequence flow out of
the event.
◆ Supported by Message and Timer events, but not Error (a process cannot wait for
an error).

19
Boundary Events
Interrupting and non-interrupting Message boundary event
◆ A catching intermediate event drawn on the boundary of an activity
(boundary event) does not signify waiting.
◆ It means while the activity is running the process listens for that signal.

◆ If it occurs before the activity completes, the sequence flow out of the event
(the exception flow) is triggered.
◆ On the other hand, if the activity completes without the occurrence of the
boundary event signal, the exception flow is ignored and the process
continues on the sequence flow out of the activity (the normal flow).
◆ A boundary event has no incoming sequence flow and must have exactly
one outgoing sequence flow, the exception flow.

20
Boundary Events
Interrupting and non-interrupting Message boundary event
◆ Two types of boundary events
◆ Interrupting boundary event (solid double ring) means the activity that the event is
attached to is terminated immediately upon occurrence of the trigger signal.
◆ The process continues immediately on the exception flow.
◆ Message, Timer and Error events all support interrupting boundary event
behaviour.
◆ A non-interrupting boundary event (dashed double ring) does not terminate the
activity.
◆ The activity continues uninterrupted, and when it completes, the process continues
on the normal flow.
◆ But, in addition, upon occurrence of the trigger a new parallel path of the process
is instantiated immediately on the exception flow.
◆ In this case, the exception flow represents actions taken in addition to those on the
normal flow.
◆ Non-interrupting events are new in BPMN 2.0
◆ Message and Timer events support non-interrupting boundary event
behaviour
◆ Error boundary events are always interrupting.

21
Timer Event
Catching Timer Event
◆ Drawn with a sequence flow in and out,
a catching Timer event represents a delay.
◆ It means either
◆ wait for [specified duration] or
◆ For example, you might want to wait for a short while before retrying an
activity such as polling for posted data.
◆ wait until [specified date/time].
◆ You can also use a catching Timer to model a wait for a scheduled action,
such as a semi-monthly check run.
◆ A catching Timer event does NOT mean waiting for something to occur,
such as a response to a request; that would be a Message event.
◆ You don’t use a catching Timer event to signify that an activity “usually”
takes three days
◆ You can use a Timer boundary event to say what happens
if the activity takes longer than three days.

22
Timer Event
Timer Boundary Event
◆ A Timer boundary event acts like a
combination stopwatch and alarm clock.
◆ By convention, the stopwatch starts when the activity the event is attached to
starts, i.e., when the sequence flow into the activity arrives.
◆ If the activity is not complete by the Timer event’s specified duration or date-time
parameter, the alarm is triggered.
◆ An interrupting Timer event aborts the activity, and the process continues
immediately on the exception flow.
◆ A non-interrupting Timer event immediately triggers a parallel thread of
execution on the exception flow without aborting the activity or the normal
flow out of it.
◆ Example above (interrupting Timer boundary event):
◆ If the search for internal candidates does not complete within two weeks, you
want to abandon it and engage an external search firm.
◆ Note: exception flow and normal flow are exclusive alternatives,
so no gateway is needed to merge them.

23
Timer Event
Timer Boundary Event
◆ A non-interrupting Timer event is often more useful.
◆ If something takes too long, you usually want to keep doing it but do
something else in addition, such as notify the requester, notify the manager
or get additional help.
◆ Since it does not terminate the activity it is attached to, a non-interrupting
Timer event could be triggered multiple times (e.g. label every hour).
◆ Example above (non-interrupting Timer boundary event):
◆ If it takes more than 4 hours to complete a service request, you want to notify
the manager but keep performing the service.
◆ The exception flow is triggered at 4 hours after Perform service starts, but it
does not terminate Perform service, and after completion the process
continues to Send invoice.
◆ With non-interrupting events, the normal flow and the exception flow are
performed in parallel.
◆ Here we join the normal and exception flow paths directly to the end event,
since a gateway is not used to join into a None end event.

24
Timed Interval
◆ A Timer boundary event measures the time from start to completion of a
single activity, but what if you want to time the interval from point A to
point B in the process, spanning multiple activities?
◆ Wrap the fragment from point A to point B in a subprocess, and attach the
Timer event to the subprocess boundary.

25
Timer Event vs. Gateway
◆ Example: A wireless carrier’s Add Plan Features process
◆ Adding the features is supposed to take no longer than one hour. If it does,
we want to notify the customer with the expected completion time.
◆ Question:
Does the customer notification occur at the same time in both diagrams?

26
Message and Message Flow

◆ BPMN 2.0 defines a message as the content of a communication between

two participants.
◆ In an executable process, that could be a SOAP or JMS service; in most
process models it is more likely some form of human communication, e.g. a
letter, fax, email, phone call.
◆ It can even represent a material flow, delivery of some physical object.

◆ => messages can represent both physical and information objects.

◆ The sender and receiver of the message are different “participants”,

meaning not part of the same process.
◆ A Message must be addressed to a particular process
◆ whereas a Signal (another form of BPMN inter-process communication) may
be broadcast to any process that might be listening.

27
Send Task and
Throwing Message Event
◆ A message may be sent from a black-box pool, a throwing Message
event, or any type of activity.
◆ Recall that a message flow out of an activity signifies the possibility of
sending the message, not the certainty of it.
◆ To be able to say that a step in the process always sends the message,
BPMN Level 2 offers two ways
◆ A Send task (black envelope icon) is a task that does only one thing, send a
message.
◆ A throwing Message intermediate event does the same thing and is effectively
the same as a Send task.
◆ There are some subtle differences, which we are going to ignore here.

28
Receive Task and
Catching Message Event
◆ We have already seen that a Message start event creates a new process
instance when the message is received.
◆ We can also receive a message in the middle of a process
◆ As with sending, a message flow into a user task only suggests the
possibility of incoming message, not the certainty of it.
◆ A Receive task (white envelope icon) is a task that does only one thing, wait
for/receive a message.
◆ When the incoming sequence flow arrives, the process instance pauses; when
the message arrives, the process immediately resumes on the outgoing sequence
flow.
◆ A catching Message intermediate event does the same thing and is effectively
the same as a Receive task.
◆ There are some subtle differences, which we are going to ignore here.

29
Asynchronous and Synchronous Messaging
◆ Send and receive tasks, or throwing and catching events, represent
asynchronous communications.
◆ As soon as the process sends the message, the flow continues on the
outgoing sequence flow; it does not wait for a response message.
◆ Synchronous communications, on the other hand, means when the
process sends a message it waits for a response before continuing.
◆ A Service task is an example of synchronous communications.
◆ It’s an automated request for an action performed by some external system,
with receipt of that system’s response.
◆ The Service task is not complete until it receives the response from the
system that performs the action.
◆ If an automated function is long-running (minutes, hours, weeks),
represent it with separate Send and Receive tasks (with message flows).
◆ Reserve Service tasks for short-running actions.

30
Message Inter-
mediate Events
◆ Example of the use of throwing and catching Message intermediate
events in a process for issuing a credit card.
◆ If the Customer’s application is missing required information, the process
sends a request for it and waits for the response.
◆ Whenever you use a Message event you should draw the message flow, and
label both the event and the message flow.
◆ The event should be labelled with the action (e.g., Request X), and the
message flow should be labelled with the name of the message.

◆ What happens if the customer decides not to respond to the request?

◆ The process instance will wait forever at the catching Message event

◆ Better solution…?

31
Event Gateway

◆ Event gateway waits for response or timeout, whichever occurs first

◆ The symbol inside the gateway shape is the Multiple intermediate event

◆ On each gate there is a catching intermediate event, usually a Message

event and a Timer event
◆ Like the regular XOR gateway, an event gateway represents an exclusive
choice, but the choice is not based on a process data condition.
◆ The gate that is enabled is the event that occurs first.
◆ In the example, it’s a race between the response message and a timeout.

32
Message Boundary Event

◆ BPMN provides a way to respond to unsolicited messages, i.e., the

process is not paused waiting for a message, but listening for it while
running.
◆ A Message boundary event attached to an activity initiates the response
to the message if it arrives while the activity is running.
◆ An interrupting boundary event aborts the activity immediately and exits on
the exception flow.
◆ A non-interrupting boundary event continues the activity but immediately
initiates a parallel action on the exception flow.
◆ If the activity completes without the message arriving, the exception flow is
not triggered.

33
Multiple Boundary Events

◆ The same message may be received in multiple boundary events.

◆ Here, the message Cancel order aborts the order process and returns a
Cancel confirmation message if it is received before Ship order starts.
◆ However, if the same message is received during Ship order, a new action,
Authorise return for credit, is triggered, but Ship Order continues, and when it
finishes the process goes to Send invoice.

34
Error Event

◆ An Error event represents an exception end state of a process activity.

◆ Error events only come in two flavours
◆ an interrupting Error boundary event and
◆ an Error end event.
◆ You cannot throw or wait for an Error signal in an intermediate event, and
there is no Error start event (except in an event subprocess).
◆ An Error event on the boundary of a task simply represents the exception
end state exit from the task.
◆ There is no implied semantic distinction between testing the end state in a
gateway and using an Error event.
◆ It is perfectly fine to use Error events for any type of exception, business or
technical.
◆ You can have more than one Error event on the boundary, representing
distinct exception end states.

35
Error Throw-Catch
◆ If Check credit were a subprocess, the Bad credit Error boundary event
on the subprocess implies the child-level expansion must contain a
corresponding Error end event Bad credit.
◆ An Error end event in a subprocess throws an error signal to the boundary of
the subprocess, where it is caught by the Error boundary event and exits on
the exception flow.
◆ => Error throw-catch pattern (propagating an exception from child to parent
levels)

Parent level

Child level

36
Loop Activity
◆ BPMN provides a way to say that an activity, either task or subprocess, is
not complete until it is performed multiple times.
◆ A loop activity (circular arrow marker at bottom centre) is like Do-While in
programming.
◆ Perform the activity once, and then evaluate the loop condition, a Boolean
data expression.
◆ If the condition is true, perform the activity a second time, evaluate again etc.

◆ When the loop condition is false, the sequence flow out of the loop activity is
enabled.
◆ With loop activities, the iteration is always sequential.

◆ The number of iterations is unknown when the first iteration starts.

<=>

37
Multi-Instance Activity
◆ A multi-instance (MI) activity (marker of 3 parallel bars at the bottom centre)
is like For-Each in programming.
◆ Perform the activity once for each item in a list.

◆ In a single process instance, there are multiple instances of the activity, and
each activity instance acts on one item in the list.
◆ List: A multi-instance activity only makes sense when the process instance data
contains some kind of collection, such as items in an order.
◆ In an order process, MI activity Check stock means check the stock of each order
item.
◆ Each order does not have the same number of items, but when Check stock begins
for a particular order, you already know how many iterations will be required. It’s the
number of items in the order.
◆ This is a fundamental difference between multi-instance and loop activities.
◆ MI instances may be performed in parallel (if so, the MI marker is 3 vertical
bars).
◆ If the instances are always performed sequentially, the marker is 3 horizontal
bars.

<=>

38
Using Multiple Pools

39
OR Gateway Split
◆ The inclusive gateway, also called the OR gateway (O symbol inside),
represents conditional split.
◆ Like the exclusive (XOR) gateway, each gate has a Boolean condition, but
here the conditions are independent.
◆ More than one of them could be true, and each gate with a true condition is
enabled.
◆ If two or more are enabled, those paths run in parallel.
◆ An OR gateway split requires a condition on each of its gates.
◆ If the gate is always enabled, use the label Always.
◆ A gate with a tickmark is called the default flow, which means “otherwise”.
◆ It is enabled if and only if no other gate is enabled for the process instance.

40
OR Gateway Join
◆ If some of the parallel paths to be joined are conditional, meaning not
enabled in every process instance, you may still join them, but you use
an OR gateway, not an AND gateway.
◆ An OR gateway join is like an AND gateway join except that it ignores
incoming sequence flows that are not enabled for this process instance.
◆ In the example below, either one or two of the flows could be enabled in any
process instance. The OR gateway join ignores the incoming sequence flows
that are not enabled in this instance.

41