Short circuit of parallel multi-instance

[herrier]

Hi there, I have had a look but struggling to find an answer for this one. Would appreciate any help on this modelling question. The requirements are:

• A request is submitted for approval by a list of approvers
• The approvals run concurrently as a multi-instance parallel user task (may take hours, days, weeks to get a decision)
• If any approver “rejects” then cancel this approval phase and loop back round

This is an interrupting boundary event, but should I model this with an error event? I can throw such an error from the task completion delegate.

Alternatively, I thought of an interrupting conditional event based on a “rejected” process variable that I could set in completion of the user task. Perhaps this is more natural as “rejection” is not an error as such, but a legitimate part of the usual business process?

I think both of these approaches look ok, now that I write this. I am using Camunda 7 latest version if that has any influence on the choice of approach.

Thank you!

[Niall]

I would go with the conditional event in this case.
The condition is clear - If the task is completed and approve = false it’ll return back to the start and cancel other instances of the multi-instance.

It’s not really a business error - usually you’d want to use an error event in a case where something is preventing the user from doing their work. But that isn’t the case here.

[herrier]

Thanks @Niall - a follow on from this scenario, I wonder how it could work:

Adjusted requirements:

• if any approver rejects (with a reason) then the flow loops back
• After a possible change is made to the request, only the rejector is asked for re-approval

I think this is hybrid requirement between:

• Wait for all decisions and loop back if anyone rejects
• Loop back immediately if anyone rejects

Like this?

[DatyEighty]

This won’t work as expected.

Let’s say you have 5 approvers and you end up with 3 approvals and 2 rejections.

Once all decisions have been made, the process will continue to the gateway where it will end in the no branch. I guess thats expected.

Each rejection will loop back, yes. However, each rejection that changes to an approval will flow to the gateway as well. Effectively this means that the “Everything is ok” task will be activated twice in this example.

You could put the first three tasks in a sub process to get the intended behavior. The process might still be a bit difficult to read though.

I suggest experimenting with the token simulator or actual process engines to see how the process behaves.