This blog post is part of a blog post serie about humantask assignment. You can find the starting point of this series by following the next link.
This post handles the assignment of a task to the same participant as the one who handled the previous task (sticky user). To demonstrate this I have extended the example of the blog Humantask Assignment: current lane participant. A second humantask is added to the process. This task is assigned to the same participant as the previous task. The following picture shows the resulting composite.
The second humantask is created with almost all the defaults settings. Instead of selecting ‘anyone in role’ as performer the ‘previous performer’ is selected. That’s all the difference.
After deployment of the process and assigning the role to an existing user in the BPM workspace ..
.. we can start a new instance via the EM.
Opening the BPM workspace and login in as one of the assigned users will show the open first humantask.
The task form is not actually created but the task does exist, and the outcome can be set via the menu.
After approving the task, the task has the following trace.
As you can see the task is assign to the role TaskAssignmentTemplate.FirstTaskRole and is handle by taskuser1. This means that the second task also should be handled by taskuser1. The task is assigned to taskuser1. As a result of this, taskuser2 who is also a member of the swimming lane role won’t see the task in the BPM Workspace. Taskuser1 has restricted access to the task.
This brings me to the end of this example. From here you can download the sample project.