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 a different participant as the one who handled the previous task (four-eyes principle). This is the opposite of the blog Humantask Assignment: same lane participant. The difference is in the definition of the second humantask. For the rest it’s all the same. The following picture shows the resulting composite.
The BPM process model
The second humantask is similar to the first humantask. The performer of both the tasks is ‘anyone in role’ / ‘Current Lane Participant’. 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.
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 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. Both taskuser1 and taskuser2 will see the task in there BPM workspace. Only taskuser2 can handle the task. Taskuser1 does not have the menu options to handle the task.
The trace of the second task
This brings me to the end of this example. From here you can download the sample project.
Hi Marcel:
I have a question, if I have a user that have 2 roles (swimlanes) , that is role1 for Task1 and role2 for Task2, and I want to apply four eyes principle in these 2 tasks, basically, that user that completes task1 cannot acquire task2, what would be the right procedure.
Lets assume that that Role1 has many other tasks and I cannot apply “exclude previous line participants”. Would it work just adding the user to the “excludeParticipants” filed of the 2nd task? Because it seems it only works in case of both tasks having same swimlane.
Thanks
Hi Luis,
If the tasks are not in the same swimming-lane the method described in this blog won’t work.
In that case you need to use more advanced features.
At a customer site I solved this situation by using Advanced Business Rules.
In short a description of this solution (somewhere in the near future I will write it in a blog as part of this series).
First I stored the username of the participant who handled the first humantask.
In the second humantask I stored the username in one of the customfields in the task-payload.
For the assignment of this task, I used ‘Advanced Rules’.
Assigning the task is done via this business rule.
In this rule the task-payload (including the stored username) is available to determine the assignment.
Hope this will help you for now.
Kind Regards,
Marcel