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. A process is not represented by a graphical object because it is actually a set of 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. A task will usually be performed by an end-user, application, or both. A sub-process shares the same shape as a task object: a rectangle with rounded corners.
A sub-process is a process that is included in another process. A sub-process can be collapsed or expanded to show or hide its details within the view of the process that it is contained in.
A business process can include many different activity types, such as:
- Tasks, which can be performed manually, with IT systems support, or completely automatically
- Tasks or sub-processes, which can be performed once or repeatedly
- Sub-processes, such as reusable, transactions, events, or ad-hoc
BPMN supports a diverse range of 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’. Let’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 found 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: sub-processes 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, but let’s look at 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 task in a process model. A modeler should be aware that a sub-process should only be 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.
Solution. Use a sub-process if you intend to decompose it into sub-elements. Use a task if you are not planning on describing sub-elements.
Mistake 2: Using Loops Instead of Multiple Instances
Problem. When using an activity loop, BPMN practitioners can struggle to decide on using a standard loop or multiple instance marker. This isn’t helped by how the BPMN 2.0 specification divides multiple instance activities into ones that are sequential or parallel.
Solution. Use the following rules when modeling activity loops:
- 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 met. 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 their employees, he or she will need to evaluate them many times, each time with different data. In a case where this work can be done in parallel, 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, or 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, a 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 exist, 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.