BPMN models can contain two types of activities: Tasks and sub-processes. Tasks are not subdivided. Sub-processes, on the other hand, contain other detailed processes.
The process in figure 103 comprises the three tasks “Enter Application”, “Invite to Interview”, “Reject Application”, and the Sub-Process “Review Application”. The latter is marked with a little “+”-Symbol. The fact that “Enter Application” is a task does not mean that it cannot be further subdivided, but simply that this has not been done in this model.
Figure 104 shows the details of the sub-process “Review Application”. When in the parent process a token arrives at this activity, the sub-process’s start event is triggered, i.e. it creates a token. The token flows through the sub-process just like through any other normal process. At some point it reaches one of the two end events. By this, the sub-process is finished, and in the parent process a token is emitted to the outgoing sequence flow.
In the parent process, it does not matter which of the two events has been reached. It is only required that the sub-process has been finished completely before a token is passed on.
In the example, however, it is important with regard to contents which end event has been reached because the following gateway distinguishes whether the result of the review has been positive or negative. However, according to the BPMN syntax, there is no relation between the different end events within a sub-process and the conditions at the decision in the higher-level process.
Figure 104: Sub-process “Review Application”
These models rather have to be interpreted in the following way. The sub-process creates data which contain the review result. These data are then available in the parent process. They will be evaluated by the gateway conditions. As already mentioned it is always assumed that all data within a process are available everywhere. This is also true for embedded sub-processes.
The parent process in the example could have an attribute “result” which can receive the values “positive” or “negative”. The annotations in figure 105 describe for each activity which value is assigned to this attribute. The conditions at the gateway in figure 103 simply evaluate the attribute value for making the decision. The conditions at the gateways in the sub-process can also make use of the result attribute.
Figure 105: Storing the review result in an attribute
Figure 106: Alternative modeling of the sub-process
The proposed mechanism for transmitting a sub-process’s results to a parent process is independent from the end events. Therefore, the sub-process could also be modeled as in figure 106. Here, the token always reaches the only end event, and the review result is again passed by an attribute.
The structure of figure 104, however, is more expressive and easier to understand – especially if cumbersome annotations should be avoided. Therefore, it may be a good idea to specify as a modeling convention that the reaction to different sub-process end events should be modeled as described above.
If the process is carried out manually, there is no process engine to manage an attribute “result”. Either the result is forwarded by an involved person, or it is noted on a form accompanying the process. The principle is not changed by this manual information transfer.
For a sub-process it is also possible to have several end events which are all reached via parallel paths. In this case, the sub-process is only finished when all tokens in the subprocess have been swallowed by end events.
If a sub-process is finished, one token will be emitted to each of the sub-process’s outgoing sequence flows. In the case of a conditional flow, a token will only be emitted if the conditions are true.
It should be taken care that a sub-process does not have more than one untyped start event. Otherwise, it is not clear where the sub-process starts after having been triggered by the parent process.
Besides using separate diagrams for sub-processes, it is also possible to insert the details of the sub-process directly into the model of the parent process. For this, the sub-process is positioned inside the enlarged activity symbol (figure 107).
Figure 107: Expanded representation of a sub-process within a model of the parent process
Some modeling tools also allow for expanding and collapsing sub-processes, so that the context of the entire process remains visible, and the details of a sub-process can be viewed when desired. The expanded view of sub-processes is only reasonable up to a certain model size. Otherwise, the diagrams get too large and complex, and it is difficult to understand them.
Sub-processes can contain other sub-processes so that hierarchical process models can be created, consisting of any number of levels.
Like top-level processes, sub-processes can also have implicit start events and end events (cf. chapters 6.2 and 6.3). In figure 108, all three tasks are activated in parallel when the sub-process is started. As soon as all three tasks are finished, the sub-process is also finished, and a token flows from the sub-process to the end event of the parent process.
It has already been explained that the start and end events of a process must all be either explicit or implicit. A combination of explicit and implicit events is not allowed. Since every sub-process is a process of its own, the usage of explicit or implicit events can be different to that of the parent process. Therefore, the diagram in figure 108 is correct. The parent process has only explicit start and end events; the sub-process has only implicit events.
In figure 108 the three tasks in the sub-process are executed in parallel. Therefore, the same logic could also be modeled with parallel gateways, as in figure 109.
It could be argued that the modeled contents in both figures have to be slightly different. Tasks 2, 3 and 4 are parts of a sub-process, i.e. they are on a more detailed modeling level. Therefore, it could be assumed that these tasks are more detailed tasks than Task 1. In the example with parallel gateways, all activities are on the same level and, therefore, they should have the same level of detail.
Figure 108: Sub-process with implicit start and end events
Figure 109: Modeling the process from figure 108 with parallel gateways
This argument is true if sub-processes are used for creating model hierarchies – from a high-level overview model to very detailed process models. However, in BPMN subprocesses are not only used for this purpose, but also for grouping several activities within a loop (cf. chapter 7.2), or for creating a scope that can be interrupted as a whole (cf. chapters 8 and 9). In these cases, the activities in a sub-process have the same level of detail as the activities of the parent process. Therefore, the sub-process in figure 108 may only be a grouping of activities, which even may have been created for achieving a more compact diagram than with parallel gateways. It is interesting that the BPMN specification states that the main reason for introducing implicit start and end events actually was this more compact way of modeling parallel activities [OMG 2013, p. 172].
Many activities are repeated several times in a process. This can be modeled with loops. In figure 110, a purchase for all employees is to be made (e.g. for newly designed business cards). In the beginning, the demand is identified. Since not all employees may be reached at once, this task is repeated until all employees have reported their demands. After that, an offer is obtained. If the offer is not satisfying, another offer is obtained. “Obtaining offer” is repeated until finally a suitable offer has been found. Only then the flow continues with “Place Order”.
Figure 110: Loop activities
A loop activity has a small circle-shaped arrow at the bottom. Sub-processes can also be marked as loops, both in the collapsed and in the expanded form. Figure 111 shows the process with the expanded loop sub-process.
Without any further information, a loop would be repeated endlessly. Therefore, it must be defined how often the loop should be repeated. This can be done with an exit condition. The loop is repeated continuously until the exit condition is true. In figure 110, the exit conditions are displayed as informal text annotations. For example, the activity “Identify Demand” is repeated until the condition “All employees have reported their demands” becomes true.
Instead of an exit condition, it is also possible to define a condition for the continuation of the loop. In this case, the loop activity is repeated as long as the condition is true. Only when it is no longer true, the loop is terminated.
For an automated process which is executed by a process engine, such conditions need to be defined in a specific formal language which can be processed by the engine. BPMN provides attributes for storing such conditions. The specification proposes the XML query language XPath for specifying such conditions, but it explicitly allows other languages, as well. In most cases it depends on the process engine which formal language is used.
The definition of a loop may additionally include the minimum and the maximum number of repetitions. The modeler can also specify whether the condition should be evaluated before or after the loop is performed. If it is evaluated before each loop cycle, the exit condition may already be true at the beginning, and the loop will not be performed at all. If it is evaluated after each looping, the loop is performed at least once.
For process models which will not be automated, it is recommended to use annotations. The conditions should be written as easily understandable textual statements.
Figure 112: Different ways of modeling loops
Loops can also be modeled in an entirely different way. A splitting exclusive gateway is placed behind the activity which should be repeated. One of the sequence flows runs back to a merging gateway in front of the activity. Figure 112 shows different representations of loops: With loop activities (top) and with backward running sequence flows, modeled with gateways (center) and with conditional sequence flows (bottom).
It is a matter of modeling style which of these alternatives is used. In business-level models, the backward running sequence flows are often used, because the loops become more clearly visible. For automated processes loop activities are preferred, because they are easier to handle. When using sequence flows for modeling loops, very complex, nested cycles may be created. These are very prone to modeling errors which may result in deadlocks.
Figure 113: Multi-instance activities
Another special kind of activity is the multi-instance activity. It is marked with three parallel lines at the bottom (cf. figure 113). It is used for dealing with an entire collection of objects that need to be processed. The multi-instance activity is carried out several times, once for each object of the collection.
The process in figure 113 starts with entering a delivery note. Such a delivery note usually contains several delivery items. The activity “Check Delivery Item” has to be carried out for each of these delivery items. Thus, the number of repetitions is determined by the number of delivery items. In the next step, each delivery item is compared with the corresponding order item. Therefore, the sub-process “Compare with Order Item” is also a multi-instance activity.
Multi-instance activities have attributes for specifying the elements to be processed. If formal statements are not needed, annotations can be used again, as in figure 113.
In principle, it is also possible to model the same behavior with loops (loop activities or backward running sequence flows). This is shown for the activity “Check Delivery Item” in figure 114. However, if a multi-instance activity is used, the rather trivial support tasks “Select First Delivery Item” and “Select Next Delivery Item” can be omitted.
A multi-instance activity is also different from a loop activity. For a multi-instance activity, the number of repetitions is known in advance since this is determined by the size of the collection of objects. For a loop activity, however, the exit conditions need to be tested after each repetition. Therefore, the number of repetitions does not need to be known in advance. In many cases, the exact number only turns out during the execution of the loop.
In contrast to loop activities, multi-instance activities do not necessarily need to be repeated sequentially in a certain order. The different objects can be processed in any order, and also in parallel. If a sequential processing is required, the three lines of the multiple marker are drawn horizontally.
Figure 115: Sequential and parallel multi-instance activities
Figure 115 illustrates this with a process of a talent show on television. First, each candidate delivers a performance. The group of candidates is known in advance. A loop activity would not be the right choice for this because then after each performance it would have to be checked whether there is still another candidate who wants to perform. On the other hand, the performances must not be in parallel, because audience and jury want to watch all performances. “Performance” is thus marked as a sequential multi-instance activity.
After the last performance, the sub-process “Determine Score” is started. This subprocess is also repeated sequentially for each candidate. Within the sub-process, there is another multiple-instance activity: “Vote” is executed for every jury member. In this example, they vote in parallel.
Like in the case of the parallel gateway, “parallel” does not necessarily mean “simultaneously”. There is just no sequence defined. Before “Calculate Score” can be started, all votes must have been submitted.
An ad-hoc sub-process is marked with a tilde. Although the activities contained in such a sub-process are determined, the order is not known in advance, because it will only emerge when the sub-process is carried out. Typical examples are creative, knowledge-intensive processes. Which activity should be performed at what time is flexibly decided by the personnel, based on the current situation. Repetitions and parallel processing are also possible.
Figure 116: Ad-hoc sub-process
Figure 117: Expanded ad-hoc sub-process
Figure 116 contains the ad-hoc sub-process “Create Marketing Collateral”. The expanded presentation in figure 117 shows the activities which have to be carried out. Since for the most activities, the sequence is not known in advance, no sequence flow can be shown for them. At those places where a certain order needs to be followed, a sequence flow can also be drawn within an ad-hoc sub-process. For example, the activity “Print Poster” can only be carried out when the poster has been designed. Therefore, a sequence flow was inserted between these two activities. The same is true for the activities “Create Brochure” and “Print Brochure”.
The tilde as ad-hoc marker can only be used for sub-processes, but not for tasks.
The tasks carried out in a process can be divided into different types. The BPMN specification defines the following types that strongly reflect the view of process automation with process engines:
A service task is an automated function, e.g. the call of an application function or a web service.
A receive task receives a message. It corresponds to a catching message event.
A send task sends a message. It corresponds to a throwing message event.
A user task expects input from a user. This is a typical task type within a so-called “Human interaction workflow”. A user receives his due tasks in a task list from which he can select the task he wants to work on. The actual work is done by entering information into a user interface dialog.
In a business rule task, one or more business rules are applied to produce a result or to make a decision. It is common to use a business rule management system which is called by the process engine. The business rules management system then evaluates the rules that apply to the current situation.
A script contains statements which are processed directly by the process engine.
A manual task is carried out without IT support.
No type has been defined.
Except for the abstract task, the different tasks are marked with icons (figure 118).
Modelers are allowed to define additional task types and mark them with their own icons in the task symbol. However, this not supported by every BPMN modeling tool.
Until now two types of activities have been used: Sub-processes and tasks. Tasks are not decomposed any further. Normal sub-processes and tasks are part of the process they belong to. This means they depend on the process and cannot be used separately.
Figure 118: Icons for different types of tasks
In many cases, however, an activity should be re-used in several processes. BPMN provides the construct of the “call activity” for this. When a call activity appears in a process, the actual activity is defined at another place, and it will only be called from the process.
If the called activity is a task, a so-called global task will be called. A global task is defined only once, i.e. its attribute values, such as the name, the description, involved functions or web services, parameters, etc. exist only once. This task can then be called within different processes. The attributes of a global task are not defined in a graphical model, but – depending on the modeling tool – in an attribute dialog which can be opened for a call activity element.
As shown in figure 119, a call activity is drawn with a thick border. In this case, “Determine disc-aount” is defined as a global task. Process 1 and Process 2 each contain a call activity referring to this global task. A business rule task is used in this example. Global tasks can be of any task type, and also without a specific type.
Especially for automated processes, there is an important distinction between normal embedded activities and call activities. Normal activities automatically have access to any information within the process. In the example above, there could be two variables for storing the total amounts of the offer and the order. In a normal activity, such as “Create Invoice”, these values can be directly accessed and used. If variables are defined in a process, they will be visible in all tasks and sub-processes of that process – except in call activities.
Figure 119: Call of a global task from different processes
Since the activity “Determine disc-aount” has been defined as a global task, it cannot access the value of such a process variable. This is because the global task can be called from different processes. It is therefore required to be independent from the calling process. For exchanging information between a calling process and a called global task, interfaces must be defined. An interface determines input and output parameters. BPMN also provides constructs for parameters, but they are not graphically displayed in models.
Although the visibility of variables is rather a subject of executable process models, it should also be considered for business-oriented models whether an activity can be used more than once. In the following chapter 7.6, a business example will be presented which illustrates a sub-process’s dependency from the surrounding process.
A call activity can also call another process. In figure 120, the process “Put Goods into Stock” is called from two other processes. The “+”-marker indicates that the called activity is a process. This called process, “Put Goods into Stock”, itself is a normal process. It could also be performed for itself, without being called from process 1 or process 2. Thus, it is different from a sub-process which depends on the parent process. A normal sub-process cannot be called from a different process. The re-use of processes is only possible with independent processes which are included via call activities.
Figure 120: Call of a process from other processes
Figure 121: Expanded view of a called process
An expanded presentation as in figure 121 is also possible. Although it graphically appears as if “Put Goods into Stock” were a part of Process 1, this process is still defined independently. An expanded presentation of Process 2 would display the same details within the expanded call activity symbol. Modeling tools have the problem that changes in a called process need to be reflected in all process diagrams with an expanded call activity referring to that process. Therefore, the collapsed presentation from figure 120 would be more practical in most situations.
Since a called process is an independent process, it can also contain lanes. The activities can be located in other lanes than the call activity in the calling process. This means that the lane will be changed when the called process is started, and thus e.g. the performing role. In this case, the lane containing the call activity only indicates who is responsible for calling the other process and for handing over the required information. Of course, a called process can also contain message flows to other pools.
A normal sub-process should only have one start event, which should be untyped (cf. chapter 7.1). A called process, on the other hand, can have several start events. Exactly one of them should be an untyped event.
In figure 122, the process “Put Goods into Stock” has not only an untyped start event, but also a catching message start event. When this event occurs, the process is started as an independent process, i.e. without being called from another process. When called by a call activity, the process starts with the untyped start event, just like when it is triggered from the outside, e.g. by a user of a business process management system who selects and starts the process with a mouse-click.
Like a global task, the design of a process which may be called several times must be globally valid, so that this process is independent from the calling process. Here again, clear interfaces need to be defined.
In chapter 7.1, a sub-process “Review Application” has been disc-aussed. It was proposed to use the attribute “result” for communicating the sub-process’s result to the parent process. This attribute must be available to both the parent process and the subprocess. It is defined for the entire job application process, and it is also visible in the sub-process “Review Application”, so that the sub-process can assign its result to that attribute. It is then available in the parent process.
This implies that the sub-process “Review Application” depends on the parent process. The dependency is caused by using the parent process’s attribute. If this sub-process was re-used anywhere in another process, it would not work, because it would have to access the attribute “result” of the job application process.
To become re-usable, the sub-process “Review Application” must not access any attributes from the parent process. Interfaces have to be defined so that information between the parent process and the child process can still be exchanged. It must be specified which values are passed to the re-usable sub-process, and which values are returned.
Programmers know this principle: Called functions or methods should not access global variables because this would cause a narrow dependency. Independent functions or methods receive the required values as parameters, returning the results afterward.
Such interfaces are usually not graphically modeled. The exact way of specifying interfaces also depends on the tool used. A possibility for visualizing input and output data will be described in chapter 10 in the context of data objects.
Figure 123: Example process of a treatment in a hospital
The described distinction between sub-processes and called processes is not only relevant for executable processes. It can also be found on a business level. If a subprocess, for example, is always carried out by the same people and only in one parent process, then the communication between these two processes will not be very difficult. Sometimes, however, a part of a process will be outsourced to a service provider or a shared service center. They may carry out the same partial process as a service for different other processes. In such a case, the interface must also be defined, i.e. which information items, documents, etc. have to be exchanged.
A process is a genuine sub-process if it depends on the parent process. It may access data from the parent process as described above, or it may depend on previous activities or decisions of the parent process. A sub-process is used for enclosing and hiding details, thus making the parent process model more concise. The contents of the sub-process nevertheless remain an inseparable part of the parent process, and they do not make any sense without the parent process.
The process for a treatment in hospital provides an example (figure 123). First, an initial examination is carried out, followed by the admission as an in-patient. If the initial examination has confirmed that there are no problems concerning an anesthesia, the process waits for the time for treatment. At this point, the patient is anesthetized and then operated. Of course, this process does not represent the real process in a hospital, in which different kinds of treatments are carried out (some with anesthesia, some without), as well as further examinations, etc. The model is only an example for illustrating sub-processes and called processes.
It may be decided to combine the activities “Anesthetize Patient” and “Operate Patient” into a sub-process. The reason is that anesthetization and operation are detailed activities that are closely related. In larger models, the creation of sub-processes would also help to reduce the complexity of the top-level model.
Figure 124: Example process with an embedded sub-process
Figure 125: Incorrect re-use of the sub-process within an ambulatory treatment
A close look at the new sub-process “Give Treatment” in figure 124 reveals that this sub-process must not be isolated from the context of the main process. Before the patient can be anesthetized, it must be confirmed that there are no medical objections. In the main process, this has been confirmed by the initial examination (although this may be different in real hospitals). The sub-process “knows” that potential problems concerning anesthesia have already been ruled out. Therefore, it is possible to anesthetize the patient without any further examination.
If it were possible to re-use this sub-process in another process, it could be included into a process of an ambulatory treatment as in figure 125. The resulting overall process is incorrect and even dangerous; because even those patients would be anesthetized whose state of health does not allow this. The consequences would be fatal. Strictly speaking, the sub-process is not reused. It is rather a copy which is no longer connected to the sub-process from figure 124. It can be modified independently from the original sub-process.
The described sub-process is not re-usable because it depends on the parent process, as described above. A re-usable, callable process must be independent from the calling process. Interfaces must be defined for exchanging data.
Figure 126 shows a re-usable process for giving a treatment. The calling process needs to provide the information whether an examination has already been made. If so, the examination results are also provided.
Figure 126: Reusable process “Give Treatment”
Figure 127: Calling the process from figure 126
Based on the provided information, a missing examination is performed, and it is decided whether an anesthesia is possible. This process can be reused without any problems. There is a specified interface, there are no further preconditions for the calling process, and the called process does not access data of the calling process – except those data that are passed explicitly. Therefore, the process can be used for both the inpatient treatment and the ambulatory treatment, without any modifications (figure 127).
