What are Activities?
The BPMN specification defines an activity as “Work that a company or organization performs using business processes.” An activity can be atomic or compounded, and the types of activity that can be found in a BPMN-based process model are: process, sub-process, and task. A special activity is “call activity”, which allows the inclusion of reusable tasks and sub-processes in a diagram. An activity is represented with a rounded-corner rectangle and named according to the type of work that is required. Task and sub-process have their own graphical representations, whereas a process is not a specified by a graphical object because it is a set of graphical objects.
A task is an atomic activity that is included within a process. A task is used when the work in the process cannot be broken down to a finer level of detail. Usually an end-user, an application, or both will perform the task. A sub-process shares the same shape as a task object, which is a rectangle with rounded corners.
A business process can include many different activity types, for example:
- Tasks, which can be performed manually, with IT systems support or completely automatically
- Tasks or sub-processes, which can perform once or repeat
- Sub-processes, which act as transactions or sub-processes with, not clearly defined sequence of tasks, etc.
BPMN supports a diversity of different types of activities, with standardized attributes that specify their meaning and behavior. The next figure illustrates the complexity of BPMN Activities with an example of a “repeatable service-based compensation task”. Le’t’s break the shape down to its meaning:
- The task is performed by some sort of service, which could be a web service or an automated application,
- The standard loop attribute defines that the task is repeated. In this case the repetition criteria also needs to be defined
- Its compensation attribute defines the task, which can only be performed when a transaction process is canceled.
Because of the diversity of activity types and underlying modeling rules in the BPMN standard, a modeler can quickly become confused about which activity type to use in a specific context and when to apply it! Here are the most common mistakes and best practices when using activities in a process model:
Mistake 1: Using Sub-processes Instead of Tasks
Problem. BPMN modelers commonly misunderstand the two main activity types: a sub-process and tasks. They perceive a task as a “simple work unit” and a sub-process as a “more complex work unit”. This is partially true, however, let’s see a counterexample. In a real-world business process, the relative complexity of activities can be perceived or measured.
However, complexity is not a decision-making factor when selecting a sub-process or a task in a process model. A modeler should be aware that a sub-process should be only used if its details can be defined in terms of the underlying tasks or sub-processes. This means that a complex real world activity should be modeled as a task if it cannot be additionally decomposed into sub-elements, whereas a simple activity can be modeled as a sub-process if a modeler decides to additionally decompose it.
Mistake 2: Using Loops Instead of Multiple Instances
Problem. It is often unclear which type of Activity loop should be use: a standard loop or a multiple instance marker. Furthermore, the BPMN 2.0 specification divides multiple instance activities into ones that are sequential or parallel .
- Use a standard loop marker (curved arrow) when an activity has looping behavior, which means that it loops for as long as the underlying looping condition is true. This condition must be evaluated for every loop iteration, and may be evaluated at the beginning or at the end of the iteration. In addition, a numeric cap can be optionally specified. If this occurs, then the number of iterations may not exceed its cap. The loop iteration condition can be explicitly defined with an intermediate conditional event (as presented in figure 7).
- Use a multi-instance marker (three vertical or horizontal lines) when several activity instances are needed. This means that an Activity is performed many times with different data sets. For example, when a company’s manager receives reports from his employees, he or she will need to evaluate them many times, each time with different data. In case this work can be done in parallel, and the activity Multi-Instance marker for parallel instances should be used (three vertical lines). Conversely, if the work can be performed only sequentially, the activity Multi-Instance marker for sequential instances should be used (three horizontal lines).
Problem. Activities are commonly classified into different lanes according to who performs or is responsible for them. Based on this presumption, a modeler might incorrectly model a business process in the following way (figure 8):
- Task 1 is performed by Person B,
- Task 2 is performed by Person A,
- Task 3 is performed by both persons.
This approach is wrong. A flow element (activity, gateway and event) can be positioned only within a lane and not between lanes.
Solution. The most common solution in this case is to create two of the same activities, positioned into separate lanes (figure 9). In this case, the outgoing flow from the previous task (Task 2) is split into two flows, leading to Task 3 for both individuals. The split of flows can be uncontrolled (without a gateway, as presented in figure 9) or controlled (with a parallel gateway). Note that some BPMN tools do not allow several activities to be named identically. In this case, an descriptive label can be added to the task’s name (e.g. Person A’s Task 3).
We have introduced the concept of BPMN Activities, which are used to represent “work” that needs to be done within a business process. BPMN allows the hierarchical composition of atomic activities (tasks) into compound activities (sub-processes). In addition to this, attributes can be given to activities in order to specialize their meaning and behavior.
However, whilst many different activity types exists, a modeler might quickly choose the wrong activity type. This could lead to misinterpretations or even incorrect executions of process models. In this article, three common mistakes, related to the incorrect use of BPMN Activities were presented, together with their solutions.