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, 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)
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.
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.
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.
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"
This event marks the end of the process, as it's representing the process goal. Hence, it can only have an incoming sequence flow.
Intermediate Events as Milestones
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.
Example: Intermediate Events as Milestones
Select each level in the figure for more information.
Key Takeaways - BPMN Events
We've only used unspecified events so far (so-called "plain 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 Events
All events have 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:
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.
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.
The Most Common Event Types
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.
Example: Ordering a Pizza (1/3)
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.
Example: Ordering a Pizza (2/3)
The intermediate throwing message event can also be used to 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.
Example: Ordering a Pizza (3/3)
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)
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.
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 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.
Select 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 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 Learned Event Types
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 canceled 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
Select each level in the figure for more information.
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
In the current way 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 reacts to it.
Example: vent-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)
Example: 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.
Select each level in the figure for more information.
Key Takeaways - Event Based Gateway
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.
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 canceled 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.
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.
Congratulations! You've completed the lesson Events - Act and React!