Figure 65: Types of events: start, intermediate, end
An event is used to express that something has happened. It indicates a point in time. In contrast to an activity, it therefore does not have any duration. When modeling an event, two aspects are considered: The cause or trigger of the event, and its effect in the process.
Examples of typical triggers for events:
Such an event and its effects are well-known to everyone whose alarm clock rings at a preset time.
As opposed to an absolute point in time, the relative time span after another event or after the end of a preceding activity is considered. As an example, a kitchen timer is preset to a certain baking time when a cake is put into the oven. The timer’s signal indicates the event “baking time completed”. It is followed by other activities for preparing the cake.
Such a condition could be “the outdoor temperature is at least 30°C”. When reaching this temperature, it may be necessary to activate an air conditioner. Another example is the specification of “stop loss” limits for stock accounts. In order to avoid significant losses, a particular minimum price can be defined for each stock. If the stock price falls below this limit, the bank automatically sells this stock.
For example, the outage of a system may require certain process steps in order to restore that system. Sometimes it is also necessary to find workarounds that enable important tasks to be performed without the system. Incoming orders may be temporarily recorded by hand. Later, when the outage is over, they are entered into the system.
Further examples of errors may result from incomplete or inconsistent data, or a message that cannot be delivered.
The examples in the previous chapters already contained start and end events. However, events can also play a role within a process. Then they are modeled as intermediate events. Figure 65 shows the symbols of different event types: The start event is represented by a circle with a single line. The intermediate event’s circle is drawn with two lines. In the end event’s symbol, the space between the two lines is filled so that it has a thick border.
Figure 65: Types of events: start, intermediate, end
If required, the presented basic symbols can be complemented with icons for different kinds of triggers, such as messages or timers.
In figure 67, the different usages of events are shown using the example of a job application. This collaboration will be explained in several steps. The fragment in figure 66 shows the beginning of the process with a start event. The trigger of this event is not determined further. As a rule, such a process is started by a process participant, in this case, the applicant.
After the activity “Write Job Application”, the intermediate event “Application sent” occurs. It is marked as a throwing message intermediate event, and it has an outgoing message flow “Application”. This event is followed by another event, the catching message intermediate event “Confirmation received” with an incoming message flow “Confirmation of Receipt”. This event only occurs when a confirmation of receipt actually has arrived. Until this moment, the process waits at this position, i.e. there is a token in front of the event. This token only moves on after the required message has been received.
Figure 66: Start of the applicant’s process (fragment from figure 67)
Figure 67: Example of the use of events
Figure 68: Start of the enterprise’s process (fragment from figure 67)
What happens in this collaboration in the other partner’s pool, i.e. in the enterprise? As the detail in figure 68 shows, the entire process is triggered by a catching message start event. Every time an application is received, a new process instance is created. In this instance, the first step is to write a confirmation of receipt. The intermediate event “Confirmation sent” follows. The process continues without interruption, and the activity “Review Application” is performed.
Sending the message “Confirmation of Receipt” has a direct effect on the applicant’s process. In this process, the intermediate event “Confirmation received” has been waiting for this message. Now, the sequence flow in the applicant’s process can be continued.
Here, the model has a disadvantage: If the applicant does not receive a confirmation of receipt, his process cannot be continued. If the enterprise would change its process and send an invitation to an interview without a previous confirmation of receipt, the applicant’s process would not be able to handle it.
The second part of the enterprise’s process is shown in figure 69. After “Review Application”, the flow is split by an exclusive gateway. If the applicant is not suitable, the process finishes at the end event “Rejection sent”. This is a throwing message event. Thus, when the process is finished, the message “Rejection” is sent.
Figure 69: Second part of the enterprise’s process (fragment from figure 67)
If the applicant is interesting, however, he is invited to an interview. The message flow with the invitation triggers the intermediate event “Invitation sent”. It is followed by the catching message intermediate event “Date confirmation received”. Here, the process waits for a message.
At the next intermediate event, the timer event “Time for interview”, the process waits again, until that time is reached. Then the activity “Carry out Interview” is performed. At this point, the process ends at an untyped end event. Unlike the event “Rejection sent”, it only indicates the end of the process and does not send a message.
Since there is an exclusive gateway in figure 69, the enterprise either sends an invitation or a rejection. The applicant’s process must react to these two alternatives. In the process fragment shown in figure 70, an event-based exclusive gateway is used for this.
Figure 70: Second part of the applicant’s process (fragment from figure 67)
At such a gateway, the intermediate event that occurs first determines the path to take. If a rejection is received first, the lower path is selected, and the process finishes at an untyped end event. However, if an invitation is received, the first event to occur is “Invitation received”, and the upper path is selected. In this path, the interview date is confirmed which results in the throwing message intermediate event “Date confirmation sent”. Then the applicant waits until it is time for the interview – just like the enterprise in its process. Finally, he takes part in the interview, and the process finishes at an untyped end event.
The most common start event is probably the untyped event (without an icon in the circle). For this event type, the trigger is not exactly known, or it is not important. Often it can also be concluded from the context. The above-described job application process is most likely triggered by the applicant.
Figure 71: Types of start event triggers: None, timer, message
A start event is quite often triggered from the outside of the process. Workflow management systems usually display a list of processes which can be started by a user, depending on the user’s role and rights. He selects the desired process from that list and starts it. By this, the start event is triggered within the process.
A process can also be a sub-process of another process (cf. chapter 7.1). As soon as the parent process activates the sub-process, the start event of the sub-process is automatically triggered.
Besides the untyped start event, especially timer start events and catching message start events are used in many BPMN models. When the registration deadline for a conference is reached, the conference organizers may start a process with further planning activities (figure 71, center). The processing of an order, on the other hand, is started when an order has been received (figure 71, right).
Figure 72 shows additional types of start events which are less frequently used. The conditional event (top, left) starts a process when the related condition becomes true. For example, a process for providing additional resources (e.g. employees or computing capacity) may be started when the utilization of the current resources exceeds 90%.
The start event at the top right is triggered by the reception of a signal. In contrast to a message which is always sent to a specific receiver, a signal is broadcasted everywhere.
Figure 72: Further triggers for start events. Top: Conditional, signal. Bottom: Multiple, parallel multiple.
Figure 73: Several start events
The signal for starting a process may originate from the same pool, or from a different pool and another process. Such a signal could be sent for announcing that a certain computer system is not available (“Online-system down”). This might require a reaction of several processes to this signal. In the example shown above, a process is started for manually processing the data.
Finally, there are two symbols for start events with multiple triggers (figure 72, bottom). The multiple event is marked with a pentagon. It combines several events. If one of them occurs, the process is started. In the example shown, a cleaning activity is started when either the cleaning interval has been reached or a contamination has been detected. In contrast to this, in a parallel multiple event all of the combined events must have occurred. A take-off procedure can only be started as soon as the permission has been given and the engines have been checked. As long as only one of these two events has occurred, the process will wait for the second event, before commencing.
On the other hand, it is also possible to model several start events separately. In this case, the process is triggered when one of this events occur. The process in figure 73 starts when a request for a report is received, but also at the end of the month. If it is triggered by a request for a report, an individual reporting period is set, before a report is created. At the end of the month, however, the report is immediately created. Should both events happen to occur at the same time, still two independent process instances would be started.
In this case, it would not be possible to use a multiple start event instead of the two explicitly modeled events because the activity “Set Individual Reporting Period” is only performed when the process is started by one specific event. If both events would be followed directly by the gateway, instead, they could be replaced by a multiple start event, and the gateway would not be required.
If a process has several start events, not more than one of them should be an untyped event, i.e. a circle without an icon. If a process is started from the outside, e.g. by a process engine or a participant, the process starts at its untyped start event. If there are several of them, it is not clear at which of these untyped start events the process should commence.
Figure 74: An untyped start event and a message start event as alternative triggers of a process
If there are several start events with a defined type (e.g. timer or message), it can always be determined which of them has occurred, and hence it is clear where the process starts.
If a process has both an untyped start event and one or more start events with specific types, it will be started at the untyped event if the process is triggered from outside. Alternatively, the occurrence of one of the other events (such as an incoming message) can also cause the start of the process. The process in figure 74 may be started from the outside, e.g. by a user who selects and activates the process in a workflow system. In this case, the process begins with the untyped start event, and the first activity is “Enter Order Manually”. However, the process can also be started by the reception of an electronic order, and thus by the catching message start event.
It could be considered to use several untyped start events and to distinguish them by different names. However, BPMN does not specify any means for selecting an untyped event based on its name. Such a feature could be useful for connecting processes: A named end event of one process could automatically trigger another process’s start event with the same name. Although such a connection via event names is not explicitly mentioned in the specification, there are examples of corresponding catching and throwing events which can easily be identified by a common name. Since BPMN does not rule out the use of several untyped start events, an individual modeling convention could be defined for connecting end events and start events via their names. On the other hand, other BPMN modelers may interpret such models in a different way, and modeling tools may not support this modeling convention.
In figure 75, the process “Introduce into New Position” should be started when “Recruit Employee” is finished, but also when “Job Change” is finished. The first activity to be performed depends on the preceding process. The connection is indicated by the names of the start events. The start events are annotated with the names of the preceding processes so that these can be found more easily.
It is not only possible to distinguish the different cases by using different untyped start events, but also by a single untyped start event, followed by an exclusive gateway (figure 76).
Figure 75: Connecting processes via start and end events with the same name
In both cases, the sequence of the processes must be modeled explicitly. They are connected as sub-processes in a higher-level process, as shown in figure 77. The plus sign means that there is a detailed process for this activity. Sub-processes are explained in chapter 7.
Sometimes it is suggested to connect processes via signal events or message flows. None of these solutions, however, is perfect. A signal is not only sent to a specific process, but it is broadcasted to all processes. This is not intended here because only one subsequent process should be started. In this respect, a message flow should be preferred, because a message flow runs to one specific process. However, this would imply that the two processes are independent of each other, not being sub-processes of an overall end-to-end process.
If a start event has more than one outgoing sequence flows, all of them are activated when the process starts, i.e. they behave as parallel flows.
It is also possible to model processes entirely without start events. In this case, every activity without incoming sequence flow has an implicit start event.
Figure 76: Use of an exclusive gateway as an alternative to figure 75
Figure 77: A higher level process connecting the different processes
When such a process is started, all these activities with implicit start events are activated in parallel. In figure 78, at the beginning, a computer and software are acquired in parallel. The two resulting tokens are joined in the parallel gateway before the computer is set up. The model fragment in figure 78 is, therefore, equivalent to the one in figure 79. Here, only one token is created by the explicit start event. This token is duplicated at the splitting parallel gateway so that the activities “Acquire Computer” and “Acquire Software” are also performed in parallel.
Figure 78: A process without start events
Other elements which usually have an incoming sequence flow also contain an implicit start event, if the incoming sequence flow is missing. As an example, the splitting gateway in figure 80 contains such an implicit start event.
A modeler must decide whether to use implicit or explicit start events. If there is at least one explicit start event in a process, there must not be any activities or gateways without incoming sequence flow. In most cases it is advisable to use explicit start events.
Figure 79: The process from figure 78 with an explicit start event
Figure 80: Gateways can also have implicit start events
An end event is displayed with a thick border, as already mentioned. Besides the untyped end event, which simply removes an incoming token (figure 81, left), there are also special types of end events. In the center of figure 81, there is an end event that not only consumes an incoming token but also sends a message.
In contrast to the catching message start event, the envelope symbol of the throwing message end event is filled. This principle is also valid for other types of events: The symbols of throwing events are always filled, the corresponding catching events contain the same symbols, but they are blank.
The end event on the right is a terminate event. Like an untyped end event, it deletes a token when it arrives. However, it not only deletes this single token but it also terminates the entire process, i.e. any other tokens in the entire process are also removed at the same time.
The benefit of this event becomes clear when looking at a process with several end events. On the one hand, these end events can be exclusive. In figure 82, an application is either sent by post or by e-mail. Hence, only one of the two end events can be reached. If one of these end events has occurred, the entire process is finished, because there is not any remaining token left.
In figure 83, on the other hand, the two activities “Create Graphics” and “Write Text” are performed in parallel. The start event creates a token, and the parallel gateway duplicates it. Each of the two resulting tokens flows through one of the two parallel paths. Therefore, both end events occur. Each of them deletes one token.
Figure 81: Types of end event results: None, message, terminate
Figure 82: Several end events, only one of which will be reached in a single process instance
Both activities do not necessarily run simultaneously, and they may have different durations. Thus, the two end events usually occur one after the other. If the end event “Graphics created” occurs first, it deletes one token. The process is not yet finished since there is still the second token on its way. Only when the last token has been deleted, the entire process is finished.
In both cases, it would have been possible to use only one common end event for both sequence flows, since an end event simply removes any arriving token.
In some cases, however, it is desired to terminate the entire process as soon as one end event is reached. An example can be found in figure 84. Here, again, the parallel gateway emits two tokens via the parallel sequence flows. The skills and experiences of a job applicant are checked, and his formal qualification is checked in parallel, too. If the results of both checks are positive, the two tokens flow through the exclusive gateways to the joining parallel gateway. Here they are joined to one token which eventually reaches the untyped end event “Application accepted”.
If one of the checks has a negative result, the respective token flows through the other exit of the exclusive gateway to the end event “Application rejected”. Since it is a terminate event, the other token is also deleted, and the process is immediately finished.
In the case of one negative result, the result of the other check is irrelevant, because the application will be rejected in any event. Thus, the process can be terminated immediately.
Figure 83: Several end events, which will all be reached in a single process instance
Figure 84: A terminate end event immediately finishes the entire process
If untyped end events were used, the other token would still move on. If for example, the skills and experiences are not sufficient, and the check of the formal qualification has not been carried out yet, this second activity will not even need to be started. This is achieved by the terminate event which deletes the second token, as well.
Replacing the terminate end events by untyped end events would cause a problem if the result of one of the checks is positive and the other negative. The token coming from the negative check would reach the end event “Application rejected”. The token from the positive check, on the other hand, would flow to the joining parallel gateway. Since the second token already has been deleted and cannot arrive anymore, the token would be stuck at the parallel gateway, and the process could not be finished. This problem is avoided by using terminate events.
Further types of end events are the throwing of a signal and the multiple end event (figure 85). As already mentioned, signals do not have a specific receiver, they can be received anywhere in the same process, as well as in other processes. In the presented example, the event sends the signal that a new software version has been released. Different processes can react to that signal, e.g. the sales process or a process for installing new software. For the software releasing process, however, it is not relevant which other processes need that information. Therefore, a signal is sent to everyone.
Figure 85: Further types of end event results: Signal and multiple
A multiple end event is used when the end of a process has several consequences. When the end event is reached, all the combined partial events occur. In the example, several messages are sent.
Just like start events, explicit end events can also be omitted. In this case, all activities and gateways without outgoing sequence flows have implicit end events. These have the same behavior as normal untyped end events. The models from figure 82 and 83 can also be modeled as in figure 86.
For implicit end events the same rule is valid as for implicit start events: A process may either have only implicit or only explicit end events. A mixture of both is not allowed. This also applies to start and end events: If there are explicit start events in a process, the end events must be explicit, as well. Accordingly, implicit start events require implicit end events and vice versa.
In chapters 8 and 9, further types of end events will be introduced which are required for sub-processes and for modeling compensations and transactions.
An intermediate event can be used at any arbitrary position within a process. It has an incoming and an outgoing sequence flow. Its symbol is a circle with a double-line border.
Usually, intermediate events are only modeled when
Start events can only be “catching”, i.e. they can receive something or react to a trigger. End events, on the other hand, can only be “throwing”, i.e. they can send or trigger something. In contrast to this, intermediate events can either be catching or throwing events.
Figure 87: Message intermediate events: Throwing (left) and catching (right)
Figure 87 shows examples of a catching and a throwing intermediate event. The throwing message intermediate event contains a filled envelope symbol. In this example, the intermediate event “Invitation sent” is triggered by the completion of the preceding activity “Write Invitation”. When this event occurs, the message “Invitation” is sent. At the same time, the sequence flow is continued, and the following activity “Prepare Meeting” is triggered.
It would also be possible to omit the intermediate event. The message flow would then originate directly from the activity “Write Invitation”. When the sending of the message is modeled as an event between the two activities, it becomes clear that the message is sent when the preceding activity is completed, rather than at an arbitrary point in time during the execution of “Write Invitation”.
The catching message intermediate event is represented by a blank envelope symbol (figure 87, right). It reacts to a message that arrives via the incoming message flow. When the activity “Book Invoice” is finished, a token flows to the intermediate event “Payment received”. Here it waits for the reception of the message “Payment”. As long as the payment is not received, the token remains at this position. The intermediate event only occurs when the payment arrives. Then the token flows on and triggers the activity “Book Payment”.
Of course, the received payment must be related to the invoice that has been sent by the same process instance. Since there are many instances of this process in parallel, many different invoices have been sent, and many payments are received. These payments need to be assigned to the related process instances. If this is done by a person, he will identify the correct invoice based on the invoice number that is referred to in the payment information.
If a process engine automatically assigns a received message to the related process instance, this is called “correlation”.
Figure 88 shows a timer intermediate event with a clock symbol. After a token arrives at such an event, it waits until a definite time. Typically it is not a previously determined absolute point in time, but the end of a certain time span. In figure 88, a cake is put into the oven. The activity “Take out Cake” starts after waiting for one hour.
Figure 88: Timer intermediate event
A condition becoming true can trigger an intermediate event, too. In figure 89, first the oven is turned on. The process then waits until the temperature exceeds 180°C before the cake is put into the oven.
Intermediate events can also send and receive signals. This is indicated by a filled triangle or a blank triangle, respectively. In the top process in figure 90, a throwing intermediate event signals that a new software version is available. After that, the process continues without interruption with the activity “Inventory New Version of Software”. In the process at the bottom, a defective software application is shut down. Then the process waits for the signal “New version of software available”. Only when this signal arrives, the activity “Download and Install New Version” can be carried out.
Sometimes it is necessary to split a large model to several pages. In this case, it is helpful to use links to other pages. They enable the user to follow the sequence flow when it is continued on another page. Such off-page connectors are represented by “link” intermediate events. They are marked with arrows.
Figure 91 shows an outgoing link “A” at the end of a page. It refers to the incoming link of the same name on the next page. This means that a sequence flow runs from Activity X to Activity Y.
It is also possible to model a link to another position on the same page. This is especially useful for replacing a long sequence flow connection around many other model elements. The model becomes clearer when such a long connection is replaced by a throwing and a catching link event.
The backward looping sequence flow from figure 92 can also be drawn as in figure 93. Here, the sequence flow is forwarded from the right, outgoing link “B” to the left, incoming link “B”.
Intermediate events can also be marked with a multiple symbol if there are several alternative triggers or several consequences of the event. Again, there are catching and throwing events. The latter has a filled symbol (figure 94). The catching version of this event is used for modeling that a token needs to wait at this position until one of the partial events has occurred. At the throwing multiple intermediate event, all of the combined consequences occur at the same time, as it is already known from the throwing multiple end event.
Figure 93: Modeling a loop with incoming and outgoing links
There is also a parallel multiple intermediate event (figure 95). In contrast to a normal multiple event, all combined events (e.g. the reception of several different messages) must have occurred, before a waiting token is moved on.
Figure 95: Parallel multiple intermediate event
Finally, there is also the untyped version of the intermediate event, without a symbol inside the double-bordered circle. Other than start and end events, untyped intermediate events are rarely used. In principle, it is possible to model simply that a certain state has been reached within a process. The event “Order entered” in figure 96 indicates that the order that is being processed has changed its state to “entered”. In this example, this information is rather trivial. What is more, the untyped intermediate event does neither have any effect on this process nor on other processes. Therefore, this event is normally not modeled.
Figure 96: Untyped intermediate event
Occasionally, however, it does make sense to model such untyped events. Sometimes it is useful to analyze the different possible states of an object. This can be done with a UML statechart diagram, for example. With untyped intermediate events, it can then be modeled where each state is reached in a process.
Figure 97 contains the different states of a document. The events always indicate the entry into a new state. In contrast to an event without duration, a state lasts some time. A different way of representing states of data objects will be shown in chapter 10.
How does an intermediate event handle multiple incoming or outgoing sequence flows? In the case of multiple incoming sequence flows, each arriving token is handled separately, i.e. the event does not wait for additional tokens. Several outgoing sequence flows are treated as parallel flow, i.e. for each outgoing sequence flow, a token is emitted.
Figure 97: Untyped intermediate events used for denoting the object states that have been reached
In chapter 3.1, exclusive gateways have been discussed. Such a gateway selects exactly one out of several sequence flows. The presented gateways are data-based gateways, i.e. the decision is made on the basis of provided data.
Figure 98 shows an example that has already been presented. Here, the value of a data element “distance” is used for evaluating the conditions at the sequence flows. If this value is greater than 500 km, the upper path is selected, otherwise the bottom path. Such kinds of data are relevant for the control flow, but they need not to be modeled in BPMN (although modeling of data objects is possible, as shown in chapter 10). It is always assumed that within a process it is possible to access all data from everywhere.
Figure 98: Data-based decision
Figure 99: Event-based decision
BPMN provides a second type of exclusive gateway, the event-based gateway. This gateway also selects one of several paths, but the decision is based on which event occurs. In figure 99, an invitation to an interview is sent. At the gateway, one of the three outgoing sequence flows is selected. In each of these sequence flows, the next element is a catching intermediate event. The event that occurs first decides which path to take.
If a confirmation is received, the interview is prepared. If a rejection is received, the documents are sent back. If, however, 14 days have elapsed without one of the other two events occurring, the applicant is called and reminded. Only that event is considered that occurs first. If the event “Confirmation received” occurs within 14 days, the event “14 days elapsed” does not have any effect anymore.
In contrast to a data-based exclusive gateway, the exits of an event-based exclusive gateway have no conditions. Instead, the first element in each outgoing sequence flow must be a catching intermediate event. This is required for selecting a sequence flow.
In the case of a catching message intermediate event, however, BPMN also provides another possibility. Since messages can also be received by activities, such an event can also be replaced by an activity. It must be an activity that does nothing else but receive the message. Otherwise, if the message were received later during the activity, the activity would have to be triggered before it is known whether the related message arrives first. An activity that only receives a message is classified as a “receive” activity (cf. chapter 7.4). It is marked with an envelope symbol in the upper left corner. The model fragment from figure 99 thus can be modeled as in figure 100. However, the logic of the decision is more clearly visible if events are used.
Sequence flows which have been split by an event-based exclusive gateway can be merged by an ordinary exclusive gateway. At a split it does not matter whether the selection of a sequence flow was based on data or events. It is only important that every time a token arrives only via exactly one sequence flow. In principle, the merge could also be expressed by an event-based exclusive gateway symbol, but the logic is exactly the same as that of a normal merging exclusive gateway.
Figure 100: Event-based decision with message-receiving activities
In chapter 6.2 a process has been modeled that can be started in different ways. These were represented by several start events. Sometimes this is alternatively modeled as in figure 101. Since the event-based gateway does not have an incoming sequence flow, it contains an implicit start event. Thus, the process starts and immediately waits for the first intermediate event. In fact, the process is started by the intermediate event. When using this kind of modeling, the use of several start events is avoided. Models with more than one start events may lead to misinterpretations. The meaning of the model in figure 101 is the same as in figure 73.
There is another alternative for starting a process: The event-based parallel gateway. Here, all events after the gateway must occur at the beginning. The first event causes a process instance to be created. After that, the process waits for the other events before it is continued. The same behavior can also be modeled with a parallel multiple start event. The model in figure 102 is, therefore, equivalent to the one in the lower right corner of figure 72.
Figure 101: Event-based gateway for starting a process
Figure 102: Event-based parallel gateway for starting a process
There is no event-based parallel gateway to be used after the start of the process. If a process needs to wait for several events which can occur in any order, normal parallel gateways can be used for splitting the sequence flow before these events, as well as for the merge after the events.
