Four-eyes principle for approval processes

[lsmall]

A common business scenario – known as the four-eyes principle – requires a particular business transaction be approved by at least two individuals. In other words, the same individual should not be able to approve it twice.

We have had multiple requests to support this requirement in the past and use an “excludedOwner” custom identity link to exclude the actualOwner for the preceding task from the next task. We enforce that _potentialOwner_s be assigned and the actualOwner role is assumed only when the task is claimed as opposed to assigning an actualOwner directly at design time.

We currently use a taskListener that assigns the actualOwner id of the current task to a variable which is used to assign the “excludedOwner” value with a separate taskListener on the next task.

Are you familiar with this requirement? If so, how would you recommend doing this in Flowable?

I am researching how this might be done within a sequential multi-instance task and was revisiting my efforts with the multi-instance collection handler feature:

Multi-instance collection syntax proposal

We are using the flowable extensions for multi-instance user assignment, but we would like to be able to support either a data object which contains a set of users or a string. For example, our design tool supports either a list of user/group ids associated with a role (e.g. potential owner) or a data object reference that contains a set of users/groups. We do not support a list type data object, so we are using JSON syntax: [ { "principalType" : "User…

I am exploring the possibility of doing something similar such that the handleAssignments method for the UserTaskActivityBehavior method can leverage alternative identityLink syntax. We use the following JSON syntax for participants:

        [
          {
            "principalType" : "User",
            "role" : "PotentialOwner",
            "principal" : "wfuser1",
            "version" : 1
          },
          {
            "principalType" : "User",
            "role" : "PotentialOwner",
            "principal" : "wfuser2",
            "version" : 1
          }
        ]

And the excludedOwner syntax is as follows:

        [
          {
            "principalType" : "User",
            "role" : "ExcludedOwner",
            "principal" : "wfuser1",
            "version" : 1
        ]

It might be useful to include a parse handler for custom syntax inside the handleAssignments method rather than use one or more task listeners, but for now, we would like to get your thoughts on supporting the four-eyes principle in general.