So far, our processes had a very isolated focus. They didn't consider or react on any external input (e.g. a message from a customer), except the start of the process. The entire chapter is about, using events as part of the process flow to act and react with the business environment.
Events Mark a State in a Process
Events mark a state in a process, at least at the start and at the end. The BPMN 2.0 notation counts more than 60 different events, which emphasizes their importance for business process modeling.
Events are required to show, at which place the business process has to wait for external input to react accordingly. Those events could be:
- A response from a customer
- A reached point in time
- A certain condition (e.g. budget approved)
Three Aspects When Using Events
Before we dive deeper into the world of events, it's important to know there are three aspects behind the usage of events. These aspects are helpful in understanding the event behavior and using them correctly.
- There are start events, intermediate events and end events - WHERE is an event used?
- Events can be catching or throwing - HOW is an event used?
- Events can be specified by a type - WHICH event is used?
Start, Intermediate, and End Events
Based on their occurrence in the process, events are categorized as start events, intermediate events and end events. You know already start - and end events, but let's take a closer look at intermediate events.
Blank Start Event
These events can only occur at the start of a process, as they're representing the trigger. Hence, they can only have one outgoing sequence flow.
Blank Intermediate Event
Intermediate events need to have an incoming and outgoing sequence flow. They mark a state in a process without impacting the process flow. The token just "passes through" and marks the state.
Why is this useful? Blank intermediate events can be used to highlight a certain progress (Milestone) in the process flow, for example:
- Mark a stage as "phase 2 completed"
- Mark manufacturing status "component X manufactured"
Blank End Event
This event marks the end of the process, as it's representing the process goal. Hence, it can only have an incoming sequence flow.
In some processes it might be useful to mark the state when a certain milestone has been reached. If the process gets executed in a technical environment, the time between different milestones could be measured more specifically. However, such milestones are always optional. Their importance depends on what they are actually describing in the process.
Intermediate Events as Milestones
Key Takeaways - BPMN Events
We've only used unspecified events so far (so-called "blank events"). Now it's time to be more specific when we describe a process trigger or an end event. With the need to become more concrete in specifying an event, we have to consider there is a distinction if the event gets triggered or is a trigger itself.
Catching and Throwing
All events have in one thing in common: They define a certain state, which triggers or ends the process. But how does an event reach such a state? There are two possible options:
- The event "waits" to get triggered (it "catches" a trigger from the outside).
- The event itself is a trigger (it "throws" a trigger to the outside).
This is the concept of catching and throwing events. If this is too theoretical, let's use an example:
Catching Start Event
Reacting on a Trigger
The start event is always in a "waiting" status to start the process as soon as an order arrives. It "catches" the trigger and starts the process.
Throwing End Event
Acting as a Trigger
The end event has "thrown" the trigger and set the state.
Catching events have an impact on process flows. They can:
- start processes as soon as they got triggered
- continue process flows as soon as they got triggered
Throwing events can:
be triggered at the end of the process
Very good! With the two rather theoretical aspects in mind, we can tackle now the last one! Fortunately, this is quite visual and you'll learn new BPMN elements.
All events can be specified, based on their actual nature. They can react to points in time, get triggered by messages or any other external conditions. Based on the real world, not all events be a trigger or got triggered by external influences - it depends on their type.
Manage Interactions with Messages
In most business processes, communication with external participants is an essential part of the process. However, the term and symbol "message" is not limited to letters, e-mails or phone calls. Message events represent everything, which can be received or be sent - it stands rather for "interaction" in general.
BPMN counts 4 different message events, depending on if we're receiving or sending a message.
Catching Intermediate Message Event
Example: Ordering a Pizza
The receiving of the pizza is indicated by a message event and it actually even has to be modeled by using a message event. Otherwise, the task "eat pizza" would be immediately started after the pizza has been ordered (no loss in time).
Hence, we need a message event to express:
- There is a waiting situation between ordering and eating.
- The process continues as soon as the pizza arrives or in other words it stops the process flow until the external condition (receiving pizza) becomes true.
Throwing an Intermediate Message Event
Example: Ordering a Pizza
The intermediate throwing message event can also be used model the state the order has been sent. The actual task "send order" is not necessarily required, as the state "pizza order sent" implies the task.
The throwing intermediate message event:
- implicit the task of ordering the pizza
Modeling the ordering task AND the throwing message event would be wrong, as we would order twice in that case.
All Message Events Used
Example: Ordering a pizza
In this example, we can see all four different message events.
So our process starts with receiving a new flyer and ends with providing feedback.
This explains that messages can:
- start processes (e.g. by getting triggered other ones)
- be sent within a process
- delay a process during its execution
- end a process (and trigger other ones)
React on points in time.
Due to its flexible usage, the timer event is very popular in practical modeling with BPMN. It can be used to start a process at a fixed - or relative or even a recurring point in time.
A timer event cannot be triggered by the process, so they are always "catching".
Behind this rule is a real-world logic:
- the process itself has no influence on time
- the process can only react to a current or a past point in time
Timer events are always catching events as a process can only react to a point in time - but cannot control it!
Timer Start Event
Timer start event should be used, whenever the start of a process depends on a certain point a time. There are several options how this time-based start is defined. It can be an interval, a fixed point in time or a relative point to a specific event.
Click on each element to discover the examples.
Using Timer Events
Pizza Process with Timer Event
With timer start events we have the flexibility to start our process at dinner time and order pizza. Ten minutes later, we can start setting the table to get ready for receiving and eating the pizza.
So, our process:
- starts time based, at a certain point in time
- is delayed by 10 minutes (but doesn't matter as we have to wait for the pizza anyway)
Both have in common, that the point in time is known to start or continue the process
React on (external) conditions.
Some processes start, based on an external conditions. These conditions are out of the control of the process, which means its unknown when exactly the condition is met - but the process can react to it whenever it is the case. This is the same behavior we have discussed for timer events, so it's also the same rule: Conditional events are always catching events, as they occur out of the control of the process - but the process can react to them!
Conditional Events Example
When to Use Conditional Events?
Isn't everything a condition which needs to be fulfilled? Yes, but based on our pizza example above, there are two uncertainties in the process, which are out of the control of our process:
- We can't control WHEN the oven reaches 180 degree.
- We can't control WHEN the pizza is ready - only when it's burned.
This uncertainty of the event and its fulfillment is a good indicator for a conditional event. In practice there are some other examples, where processes cannot influence the condition:
Link Events - Link Process Stages
The link event is to a certain extent a special case: It has no meaning in terms of content, but is only a technical structure element. Two links can replace a sequence flow. This aspect can be really useful in large process models especially where long sequence flows across different lanes would make the model less readable.
Click on each task to find out more.
It has no significance related to content, but it facilitates the diagram-creation process. You need to make sure to name them accordingly in order to follow the matching.
Link Events Can be Very Useful
Link events can be very useful if:
- You have to distribute a process diagram across several pages. Link events allow to link these different process models and enable a "left-to-right" navigation.
- You have a process with many sequence flows, maybe even across the entire process. Link events help to replace a long sequence flow and keep the process design easy-to-understand.
Overview of the Most Common Events
Overview of the Learned Event Types
Not every event type has an occurrence in every event dimension, as shown in the figure. It depends on their nature of being only reactive (catching), active (throwing) or even both.
Start events can only be catching.
Blank Start Event - Can always be used as an unspecified start event.
Blank Intermediate Event - Can be used as a milestone in a process. It marks a certain point in a process.
Blank End Event - Represents and unspecified end of a process.
Message Start Event - Can be used, whenever the process gets triggered by receiving a message, a physical object or anything else.
Catching Message Intermediate Event - Represents an incoming message, object or file and "waits" until that point of receiving.
Throwing Message Intermediate Event - Represents a message, physical goods to files sent to external process participants.
Message End Event - Represents a message, physical goods or files send by ending the process at the same time.
Start Timer Event - Can be used, whenever the process start depends on a certain point in time.
Catching Intermediate Timer Event - Delays the process until a given point in time. Can be used to wait for a deadline (e.g. period for payment before reacting).
Start Conditional Event - Can be used, when the process start depends on a condition which is outside of the influence of the process (e.g. an approved budget or a vacant position).
Catching Intermediate Conditional Event - Delay the process until an (external) condition is met.
Catching Intermediate Link Event - Catches the token from a throwing link event.
Throwing Intermediate Link Event - Throws a token to a catching link event.
Special Topic: Attached Intermediate Events
Since you know now the most common events in BPMN, it's time to focus on a second specialty of events. They can also be used as a cancel condition to tasks.
How does that work? Let's use again our pizza example:
Attached Timer Event
Using the timer event as cancel condition.
In this example, we can't decide on a pizza. Hence, after 10 minutes we give up and decide to cook pasta instead.
That means, when we attach a timer intermediate event to a task:
- it defines a cancel condition, based on a time
- we can model an alternative way to the cancelled task and proceed with the process
Attached Mixed Events
Multiple Cancel Conditions
With our cancel condition on choosing a pizza, it can also happen the pizza is not available when we're calling the pizzeria. In this process example we want to make sure, we can still eat pasta and not get starved.
- All catching intermediate events can be used as cancel conditions for tasks
- For each attached intermediate event, there must be an alternative path - which can also be the same one
Key Takeaways - Event Types
Reacting on Decisions Made Outside of the Process
So far, we just considered decisions made as part of the process - and used XOR gateways to route the result. Whenever customers or other external participants are involved, we might need to react to decisions made by them in order to proceed with our process accordingly.
The BPMN has a dedicated gateway to be used to model such cases, the Event-based Gateway.
Reacting to Decisions Made Outside the Process
What happens when the Pizza never gets delivered? In the current form the process would get stuck at the catching message event. In practice, it can actually happen we don't get what we've requested or doesn't get at response at all. In that case, we need to think of alternatives to ensure the process can still proceed and doesn't get stuck (and waits forever for an event).
The Event-Based Gateway
The event-based gateway waits for the following intermediate events to happen before it steers the process flow. Whichever of the events happens first is the path that will be taken at the gateway.
The decision is made outside the process, and we or the event based gateway just react to it.
The Event-Based Gateway
Modeling Event-Based Alternatives
In our previous example, it might still be the case we never receive the pizza. How long should we wait? The following process shows a way of modeling an exit of the loop while still not losing the possibility of receiving the pizza.
- We can always receive the pizza
- We have an alternative to call the pizzeria 3 times
- We have an exit, if we don't get the pizza after calling 3 times (90 minutes in total)
Modeling Event-Based Alternatives
Since the event based gateway works in a way of "reaction" to events, there can only be catching intermediate events connected to it. The token waits for the next event occurs in order to proceed.
Key Takeaways - Event Based Gateway
Modeling Exercise - Order Processing (Part 2)
The management of MyStore Inc. is not happy with the previous process and also faces the problem that numerous orders have not been paid yet. In the near future, orders must only be shipped after prepayment. In addition, the process will be extended by the case of missing payment after an order. Therefore, the existing process model has to be adapted again in consideration of these new findings.
Process Modeling Task
Revise your existing process model, so it reflects the following change in the process.
The invoice is not created by the order acceptance department as before, but is now created and sent by the finance department. If payment is received within seven days, the warehouse sends the goods to the customer while the finance department confirms receipt of payment to the customer. If a payment period of 7 days elapses without the customer having paid, a payment reminder is sent. If payment is still not received after a further 5 days, the order will be cancelled and the customer will be informed.
- Transform the process description into a compliant BPMN 2.0 model. We recommend using and editing your model from exercise part 1. You can also create a copy to keep your initial version.
- Please only use the elements you have already learned and model from the perspective of the MyStore company. There is still no need to include external process participants.
Estimated time effort: ~ 45 min.
Modeling Tip 1- [SMALL SPOILER]
You should use 2 event-based gateways to capture the different possible events, which take place based on the customer "reaction".
Modeling Tip 2 - [BIG SPOILER]
Consider this blank shape model as a design orientation.
If you think you are done, check your solution again for syntax, semantics and naming conventions. Also think about a user-friendly and readable look and feel for your diagram.
If you feel confident with your results, view the sample solution and compare with your own.
Signavio Solution to the Order Processing - Part 2
Congratulations! You've completed the section on Events - Act and React!