Events - Act and React

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.

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.

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.

Select each level in the figure for more information.

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.

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:

1. The event "waits" to get triggered (it "catches" a trigger from the outside).
2. 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:

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.

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

Note

Start events are always catching events!

Throwing events can be triggered at the end of the process.

Note

End events are always throwing events!

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.

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.

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.

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.

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:

1. start processes (e.g. by getting triggered other ones)
2. be sent within a process
3. delay a process during its execution
4. 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:

1. the process itself has no influence on time
2. 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 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.

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

Note

Timer events can only be used, when 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!

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.

Note

The name of two link events need exactly to be equal for matching.

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:

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

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.

To summarize:

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

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.

Note

In business processes, it's often necessary to react to external influences.

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

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.

More specifically:

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

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.

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.

Note

There are of course several solutions for this task. However, you should have covered the same subject matters. Of course, the names of the individual elements and overall design may differ slightly.

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!