Events - Act and React

So far, our processes have had an isolated focus. They didn't consider or react on any external input, such as a message from a customer, except at 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 can be:

• A response from a customer.
• A reached point in time.
• A certain condition, such as a budget approved.

Before we look at the world of events, it's important to know there are three aspects behind the use of events. These aspects are helpful in understanding the event behavior and using them correctly.

1. There are start events, intermediate events, and end events. Where is an event used?
2. Events can be catching or throwing. How is an event used?
3. Events can be specific by a type . Which event is used?

Based on their occurrence in the process, events are categorized as start events, intermediate events, and end events. You already know start and end events - let's review them and 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 must 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 is useful to mark the state when a certain milestone has been reached. If the process is applied 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.

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 that there is a distinction if the event gets triggered or is a trigger itself.

1. There are start events, intermediate events, and end events. Where is an event used?
2. Events can be catching or throwing. How is an event used?
3. Events can be specified by a type. Which event is used?

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 when 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 when they are triggered.
• continue process flows when they are triggered.

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

Very good. With the two rather theoretical aspects in mind, we can now tackle the final one. Fortunately, this is 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 and are 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 four different message events, depending on whether we're receiving or sending a message:

The receiving of the pizza is indicated by a message event and it must 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 when 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 in that case, we would order twice.

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. For example, by triggering 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 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 start event must 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.

Let's look at our pizza process again, to see how timer events can be used.

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 ten minutes. However, this delay doesn't matter as we must wait for the pizza anyway.

Both have in common, that the point in time is known to start or continue the process.

Some processes start based on 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's the case. This is the same behavior that we have discussed for timer events, so it's also the same rule:

Isn't everything a condition that must be fulfilled? Yes, but based on our pizza example, 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 degrees.
• 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:

1. When a job position gets vacant (to trigger the hiring process).
2. When an idea is available (to trigger an innovation process).
3. When a minimum amount of items in stock is reached (to trigger the order process).
4. When most votes are available (to proceed in the process).

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 is useful in large process models especially where long sequence flows across different lanes makes the model less readable.

It has no significance related to content, but it facilitates the diagram-creation process. To follow the matching, ensure to name them accordingly in order.

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

Not every event type has an occurrence in every event dimension, as shown in the table. It depends on their nature of being only reactive (catching), active (throwing), or even both. As you may remember, start events, for example, can only be catching.

Since you now know the 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 our pizza example again.

Attached timer event: Using the timer event as a 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 that when we attach an intermediate event, a timer, 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 that 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.

So far, we 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 must react to their decisions before we proceed with our process.

The BPMN has a dedicated gateway to be used to model such cases, the Event-based Gateway.

In our current method, the process would get stuck at the catching message event. If we don't get what we've requested or don't get at a response at all, we must consider alternatives, to ensure that 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 happen first is the path that is 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 that we never receive the pizza. How long can 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 three times.
• We have an exit, if we don't get the pizza after calling three 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. To proceed, the token waits for the next event to occur.

The management of MyStore Inc. is unhappy with the previous process and also faces the problem that numerous orders have not been paid yet. Soon, orders must only be shipped after prepayment. In addition, the process is to be extended in the case of missing payment after an order. Therefore, the existing process model must be adapted again in consideration of these new findings.

Revise your existing process model, so it reflects the following change in the process.

The order acceptance department do not create the invoice as before. The finance department now created and send the invoice. 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 seven days elapses without the customer having paid, a payment reminder is sent. If payment is still not received after a further five 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 the Part 1 exercise. You can also create a copy to keep your initial version.
• Only use the elements that you have already learned and model from the perspective of the MyStore Inc. company. There is still no need to include external process participants.

Estimated time effort: Approximately 45 minutes.

Modeling Tip 1: Use two event-based gateways to capture the different possible events, which take place based on the customer "reaction".

Modeling Tip 2: Consider this blank shape model as a design orientation.

If you think that you are finished, 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 it to your own.