Humantask Assignment: sequential participants (four-eyes principle & sticky user)

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.

If you look at the example in Humantask Assignment: not the same lane participant as previous task (four-eyes principle) you see two sequential humantasks. If these humantasks are both connected with the same task form there might be another method available to model the four-eyes principle. Namely: assigning participants sequentially to the same humantask. This means that there will be only one humantask in the process model.

Open the task file and add a sequential participant block by clicking the green plus sign and then selecting the ‘sequential participant block’ menu option. In the example I used the default name “Stage1.Participant1”. Be sure that both participant are set to the current lane participant. It’s the same as in Humantask Assignment: not the same lane participant as previous task (four-eyes principle). This means that it is possible that both tasks are handled by the same representative. And this is not what we want…

We need to change an overall task setting. For this select the pencil in the right upper corner.

Select the assignment tab. At the bottom you see the field “Participants Exclusion List”. In here select the “Previous Lane Participant”. This will do the thing. Now the four-eyes principle is implemented. Is it?

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. Because of the sequential assignment the task is not closed yet but it is reassigned to the next participant. This means that the second assignment should not be handled by taskuser1. As a result of this, taskuser2 who is also a member of the swimming lane role must handle the task. If we compare it with Humantask Assignment: not the same lane participant as previous task (four-eyes principle) then both taskuser1 and taskuser2 will see the task in there BPM workspace where only taskuser2 can handle the task.
In this case, this is not true. Both participants can handle the task. To me this is an unexpected result. I was expecting the same behavior as in the example with two tasks.
The trace after handling the task by taskuser1 again.

Lets see if we can change the example to the sticky user example of Humantask Assignment: same lane participant as previous task (sticky user) to find an explanation for this behavior. For this change the assignment of the “Stage1.Participant1” to “Previous Lane Participant” and redeploy the process. After testing this I became a bit confused. The sticky user seems to work fine. Am I doing something wrong, is it not implemented or is it a bug?

As a conclusion, using sequential participants assignment simplified the process model, but in this simple form the functionality is limited. Sequential participants assignment is not solving the four-eyes principle requirement. The sticky user requirement is working fine but I do not really can think of a use-case for it.

This brings me to the end of this example. From here you can download the sample project.