Managing The Task Lifecycle

The lifecycle of human tasks (like assigning, delegating and completing tasks) is mostly a generic issue. There is no need to model common aspects into all your processes, if often makes models unreadable. Use Camunda task management features or implement your requirements in a generic way.
Managing The Task Lifecycle is also related to
Managing The Task Lifecycle

Using Camunda Task Lifecycle Features

Do not show the lifecycle of user tasks in the process model, they are generic and common to all processes and so can be controlled by using the the Camunda BPM task lifecycle & management features.

task lifecycle

Keep in mind when modeling, that there is a task lifecycle "behind the scenes" for every user task. This means that you can perform the operations shown below on every user task (without the process moving forward). Therefore, restrict yourself to including only the steps in your BPMN model which work towards the goal of your business process or deal with business related problems on the way to that goal.

Lifeclycle Operation Use Cases API for explicit call


New tasks are normally created as part of process execution, but can be created by an user action, too (as standalone tasks).


Set Candidate

Typically candidates are initially set to groups of people as part of process execution, but can be requested by API, too.

taskService.addCandidateGroup(taskId, groupId)


Individual members of a candidate group assign themselves to tasks when working on them.

taskService.claim(taskId, userId)


Individual assignees unassign themselves and move a task back to the candidates.

taskService.claim(taskId, null)


Directly assign a specific individual either as part of process execution, or because explicitly requested by API.

taskService.setAssignee(taskId, userId)


Individual assignees may want to hand over a task to somebody else.

taskService.setAssignee(taskId, userId)


Individual assignees may want to delegate (part of) the work: ask somebody else to resolve (part of) the work in order to pass the task back subsequently.

taskService.delegateTask(String taskId, String userId)


After having resolved the requested work individual assignees will want to pass a delegated task back to the owner: the original assignee

taskService.resolveTask(String taskId)


This is how you would close the work on a task and asking the process execution to move on

taskService.complete(String taskId, String userId)

Assigning Tasks to Groups of People

As a general rule, you should assign human tasks in your business process to groups of people instead of specific individuals.

<bpmn:userTask id="Invoice customer" camunda:candidateGroups="finance"/>

If you want to change the group pre-assigned via the process definition, you can achieve this via code, but you could also do it via the Camunda tasklist. Simply click on the groups displayed next to the task and add or remove groups:


Then, require individual members of that group to explicitly claim tasks before working on them. This way you avoid different people working on the same task at the same time.

taskService.claim(taskId, "fozzie");
Of course, you can also directly claim tasks in Camunda tasklist with the click of a button.

While assigning users to groups is advised it’s not the only option. You could always assign a task to a single person who is supposed to complete the task (e.g. the individual 'customer' of your process or a coworker having specific knowledge for the case). You will need to have access to the specific person relevant for your process instance, e.g. via a process variable:

<bpmn:userTask id="Clarify invoice" camunda:assignee="${responsible_assistant}"/>

Handing Over Tasks Directly to Other People

You can always hand over a task assigned to you simply by changing the assignee. This means that the new assignee is now responsible and supposed to carry out the task all by themselves.

taskService.setAssignee(taskId, "kermit");

This can also be achieved via the Camunda tasklist:


Delegating Tasks to Other People

Delegate a task assigned to you by using Camunda "delegateTask". This means that somebody else is supposed to resolve (some of) the work and then pass the task back to you by resolving it. The original assignee is remembered as the "owner" of the task. A typical example is decision support: Some other employees collect information in order to prepare a decision, but the original assignee has to take that decision.

Even if the engine does not enforce that a delegated task can be directly completed, we recommend that you not allow this if you use delegation. The task should always be resolved and then later completed by the owner. That’s why there is no transition from "DELEGATED" to "COMPLETED" in the lifecycle shown.

taskService.delegateTask(taskId, "gonzo");
// and later
As of today it is not possible to delegate/resolve tasks using the tasklist application shipped with Camunda. You can write a tasklist plugin which adds a tab in the task form view. Or as an even easier alternative you can add this functionality to your embedded form itself.

Developing Advanced Task Management Features

Aside from the task lifecycle discussed above, there are some typical use cases when managing your tasks. Camunda provides these task management features either out-of-the-box or provides the necessary hooks to build your own custom features.

Notifying People About Their Tasks

You might want to notify people about new tasks (e.g. via eMail). Do this by implementing a Camunda TaskListener, like shown in the example shown in this implementation.

When you want to have this functionality for every user task you can use a ParseListener which adds it everywhere, so you don’t have to adjust the BPMN model. See BPMN Parse Listener to see how this can be done, and how it is hooked into the process engine by a ProcessEnginePlugin.

Following Up On Tasks After Some Time

Follow up on tasks after some definable time by using Camunda’s Follow Up Date field and use it in connection with filtering tasks.

You can set a calculated follow up date by using a JUEL expression in your BPMN file

<bpmn:userTask id="Check payment" camunda:followUpDate="${paymentService.getFollowUpDate()}"/>

You can set a follow up date, that may be requested by the user, using the Java API


Now you can use a task filter with criteria checking the follow up date and if it is due. This can be leveraged via API or in the Camunda Tasklist:

follow up filter

Enforcing Deadlines for Tasks

There are different ways of enforcing deadlines for Human Tasks. Typical actions for overdue tasks are:

  • sending reminder mails

  • changing the assignee/group

  • creating a standalone task for a manager

Explicit modeling in BPMN Filtering due tasks Querying due tasks and take action Timeout task event

Showing an escalation process path in your BPMN model (see example below)

Setting the Due Date field to easily filter for overdue tasks

Setting the Due Date field, querying it on a regular basis and take arbitrary actions

Implement a timeout event listener and configure it in the process model





Bulk actions possible
(e.g. one mail with a list of all due tasks)

No custom component required

Querying has to be done by external trigger or BPMN process

Use when

The escalation is business relevant and has to be visible in the process model

Overdue tasks can be easily monitored via tasklist application, actions are taken manually

Sophisticated, automated actions should take place

A timely escalation mechanism is desired

Don’t use when…​

Each and every User Task has a due date and explicit modeling would clutter your process model

You need an action to be executed automatically

You do not want to run your own scheduling infrastructure

The escalation should be visible in the process model


see below

see below

see below

This example shows how to explicitly model an escalation:

1 The model shows an explicit escalation process path: if the tweet does not get reviewed within an hour, the boss needs to be reminded about the laws of the Internet age.

This example shows how you can calculate and set the Due Date field:

<bpmn:userTask id="Review tweet" camunda:dueDate="${dateTime().plusHours(1).toDate()}"/>

You can easily query for overdue tasks via API, e.g. all overdue tasks:

processEngine.getTaskService().createTaskQuery().dueBefore(new Date()).list();
All methods can be used for Receive Tasks as well. Note that the Receive Task does not have a "Due Date", so you have to use a process variable instead.

This example shows how to model a timeout event on a user task:

<bpmn:userTask id="Task_1qdlz4w" name="Do something">
    <camunda:taskListener delegateExpression="${sendEmailReminderListener}" event="timeout" id="reminder-listener">
      <bpmn:timerEventDefinition id="TimerEventDefinition_1an454y">
        <bpmn:timeCycle xsi:type="bpmn:tFormalExpression">R/PT1H</bpmn:timeCycle>

Every hour, the process engine will invoke the sendEmailReminderListener bean to send out an email. The bean can access all task and process attributes.

Signing Off Work Done by Other People (4 Eyes Principle)

You might want to sign off work by a peer review - often named "4 eyes principle". Learn more about the patterns to model separate user tasks to be completed when Requiring a Second Set of Eyes. Then you have two alternative solution approaches.

Camunda Authorization mechanisms Logic in own Facade

Revoke Authorization on review task for user who has done the first task, implemented by Java Task Listeners

Check in your Facade via the engine API if the user is allowed to do the review, otherwise throw exception when claiming or completing tasks

Use when…​

You use the Camunda Authorization mechanisms

You do not use the Camunda Authorization mechanisms


1 Save the user who completed the first task in a process variable. This can be implemented using a Task Listener.
2 The second review task is technically assigned to the same group of users as the first one. But here you either revoke the authorization or add checks to your Facade.

No guarantee - The statements made in this publication are recommendations based on the practical experience of the authors. They are not part of Camunda’s official product documentation. Camunda cannot accept any responsibility for the accuracy or timeliness of the statements made. If examples of source code are shown, a total absence of errors in the provided source code cannot be guaranteed. Liability for any damage resulting from the application of the recommendations presented here, is excluded.

Copyright © Camunda Services GmbH - All rights reserved. The disclosure of the information presented here is only permitted with written consent of Camunda Services GmbH.