Requirement where a designer has create a workflow assigning multiple parallel tasks to multiple parallel groups of approvers is complex.
Basically, Nintex offers us two approaches: either assign task to a group and wait for the first response or to wait for all responses. But what when we need to have multiple groups assigned a task in parallel?
Doing multiple parallel approvals requires either parallel block or... unchecking the option for waiting until task is completed.
The first approach require the workflow to be edited every time number of parallel groups is changed - to add or remove branches. It makes it quite fixed. And therefore hard in maintenance.
The second approach is better. This way you can build a loop and in the loop assign all tasks to all groups. But what then? What if you need to pause the workflow, so that it actually waits for all the responses before moving on?
This can be done by first collecting all the IDs of tasks generated and then by using a loop to check if they are completed.
If any was completed, it should be removed from a collection. Once collection is empty the workflow can move one. Of course, after each check workflow has to pause, so that the loop won't run endlessly.
In both approaches there are challenges quite hard to overcome. The first one requires a fixed approach. If number of tasks' groups is changed - you need to edit the workflow.
The second one is even worse - because workflow has to check multiple items on the Workflow Tasks list, every 5 minutes (or slower - up to you) it may easily reach the boundary (Daily email limit has exceeded and your workflow has been suspended) of 5k calls to the SharePoint. And then it requires you to resume it after a day. Useless...
I have created a pattern that gets out the best from the second solution and allowing the workflow to overcome the limit. How?
I simply moved the need of checking if the task is completed or not to the tasks' list. And a State Machine action in the primary workflow.
Workflow is triggered by the primary workflow. It works for any task that is not yet completed (1). It pauses (2) until Task Status equals "Completed". Once unpaused, it gets related item data and extracts (3) ID of the related record, using the following pattern (the "Related Item" attributes is stored in a JSON formatted string):
Then it gets item 0 from the collection (4) and updates field of the item (5), on which the primary workflow runs, so that it can move on.
Following this approach you can build solutions that assign tasks to multiple approvers' groups in parallel, so that you can have e.g. 10 tasks each assigned to a group of 10 different persons, having completion criteria set either to wait for all responses or just a first one.
Very useful and reliable. Try it out yourself!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.