BPMN Diagrams – How To Use Tasks

This article shows how to use the different types of tasks in BPMN diagrams. Examples of normal tasks, looping tasks, multiple instance tasks and compensation tasks.

Background

We presented an introduction to BPMN diagrams two weeks ago. Business analysts are often required to document as-is processes and to-be processes. These diagrams help identify the scope of a software project. The diagrams can also help uncover requirements that might be overlooked without diagramming the processes.

The BPMN specification is designed to establish a common language and convention for creating process diagrams. This common convention allows people who are familiar with modeling, but new to a project to avoid learning a new diagramming language on each project or for each client. We have a link to the official version of the spec in our introductory post (we will update that link if and when the spec changes).

Tasks are one of two types of activities that can be included in a BPMN diagram. Each task represents an atomic activity in a business process. The other type of activity that we can represent is a sub-process. This article focuses on tasks.

BPMN Tasks

The BPMN specification includes four unique types of tasks, and two combinations of types. The following is the list of those types:

• Normal task – a single action that occurs in a business process, like “write a check.”
• Loop task – a task that repeats sequentially.
• Multiple instance task – a task that repeats, but multiple “copies” of the task can be happening in parallel.
• Compensation task – a special task that is only executed when a specified (other) task is undone.
• Compensation loop task – a compensation task that repeats sequentially.
• Multiple instance compensation task – a compensation task that repeats, but can repeat in parallel with itself.

Let’s look at examples of each of the types.

Normal Task Example

The simplest form of task is shown in the example above. Each rounded rectangle represents a single operation, performed one time. This is the same sort of behavior that people are accustomed to reading in flowcharts. This business process model shows that someone will compose their thoughts, write an email, and send the email.

Loop Task Example

Business process modeling with BPMN allows us to use a standard graphical language to communicate concepts that would require more complex diagrams using generic flowcharting techniques.

We’ve augmented the previous email process model to include spell-checking. The “Correct Spelling” task includes a curving arrow symbol that identifies it as a loop task. The spelling in the email is corrected more than one time (think of each error as a requiring a single correction). The looping continues until a boolean condition causes the looping to end. In this example, the looping ends when there are no more spelling errors.

It is important to note that the looping happens sequentially. The “Correct Spelling” task can happen more than once, but each iteration must begin after the previous iteration has completed.

Here’s how the process would look if we didn’t use a looping task, and instead used gateways to model the looping.

In this alternative model, a normal task has been modeled for the “Correct Spelling” activity. Then a data-based gateway is used to control the looping. The loop task makes for a slightly cleaner presentation of the behavior.

Multiple Instance Task Example

In the looping example above, each iteration of the looping step must follow the previous iteration. Sometimes, those iterations can happen in parallel. The multiple instance task expressly allows that looping to happen in parallel. The task has a small symbol, two parallel lines, in the center of the bottom of the rounded rectangle. This indicates that looping can happen in parallel.

In this business process model, we create a survey, collect the responses, and then compile the results and review the results. “Compile Results” is the looping task. Since each individual response to the survey can be tabulated independently, this model shows the the task as a multiple instance task.

If there is a fixed limit to the number of parallel “Compile Results” operations that can happen, it would be indicated with an annotation of the diagram. This is one of the more powerful BPMN diagramming entities. Consider what the BPMN diagram to represent parallel processing would look like without it:

The elements within the red dashed-line rectangle represent the equivalent behavior as the multiple instance task.

After responses are collected, the process flow splits (via a fork gateway) into two parallel paths. One path begins compiling a single result. The other path looks to see if there are more responses to be processed. If there are, the process loops back (via a data-based gateway). This second process splits again. One side starts a second, parallel “Compile Single Result” task. The other side starts a new “Inspect Response Queue” task. As long as there are more responses in the queue, more parallel processes will be created.

When all of the “Compile Single Result” tasks have completed and there are no more responses in the queue, the process will continue to “Review Results” (via the join gateway).

Having a multi-instance task is very valuable, because it has a precise definition for developers (as shown in the exploded diagram), yet it provides clear communication of what matters to stakeholders – there is a task that repeats until done. The stakeholders are not likely to care if the repeating task is a loop task or a multiple instance task – and can easily ignore that level of detail when reviewing the process. At the same time, an analyst or developer can quickly see precisely what is intended.

Compensation Task Example

The compensation task is a special task, and is not part of the normal flow of events. There are times in business process modeling where we need the ability to “undo” a step or process. Sometimes, when undoing, we actually want to record that something has been undone, which requires a seperate process step (represented as a task). This “undo” process might even be fairly complex, and would be represented as a sub-process. The compensation task is represented as a normal task, but with a small symbol that looks like the rewind-button on an audio player (two small solid triangles pointed to the left).

Consider the following business process modeling example of the interaction between a buyer and a seller.

In the normal flow of the business process, the buyer (on the left) will purchase an item from the seller (on the right). The seller will charge the customer for the item, then deliver the item. The buyer receives the item and the seller records the transaction.

The buyer, in our example, has a gateway that represents a future evaluation of happiness with the item. If the buyer is happy (the default path), then the process ends. If the buyer is unhappy, then the process ends with a special compensation end event. This compensation end event triggers any compensation tasks that have been defined in the process. [For programmers – the buyer process “throws” a compensation event, and the seller process “catches” it with the compensation intermediate event attached to the “Charge Buyer” task.]

The seller’s compensation task “Credit Buyer” is executed only when the compensation end event is reached in the flow of the buyer’s process. This execution is not part of the normal process flow. Note that the “Credit Buyer” task is associated with the “Charge Buyer” task with a dotted line – this indicates that there is a relationship between the two tasks, but not a flow. Conceptually, the reason the seller hase to credit the buyer is because she previously charged the buyer.

Looping Compensation Task

A looping compensation task is initiated in the same way that a normal compensation task is triggered. The difference is that the task will be repeated until it is complete.

Multiple Instance Compensation Task

A multiple instance compensation task also shares the triggering behavior of the other compensation tasks. This task will be repeated (in parallel) until it is complete – just like the multiple instance task.

Summary

Tasks are the primary element used in business process modeling. BPMN diagrams include specialized tasks that represent complex behavior. Looping can be represented sequentially or in parallel with the loop task and the multiple instance task, respectively. When a special “undo” behavior is being modeled, a compensation task can be drawn to capture the requirement.