Related links
Did You Know: The Magnificent Flexi Task – Behavior
Did You Know: The Magnificent Flexi Task – Reminders and Escalation
Did You Know: The Magnificent Flexi Task – Communication Methods
The Flexi task is one of the most popular workflow actions and we are eagerly awaiting its arrival in the o365 version. For something so powerful, how much of it do you really know? How many of the options have you used?
Today I want to concentrate on the behaviour section:
What do these options actually mean?
Like most of you, I suspect we accept the default behaviour “First response applies” and carry on happily knowing that a single person is going to make a decision on an action and their decision is final. Things, however, start to get a little trickier when multiple people are involved.
Let’s start by way of an example:
We have a situation where the flexi task is has two outcomes (Approve and Reject) and it is sent to two people. In order to continue, we want both of these people to approve the task. If either of the people reject the task, we want the workflow to manage the outcome as if it was rejected. Sounds simple enough right? Surely you just select “All must agree on a specific outcome”, set the outcome to “Approve” and away you go?
Let’s try it out. I’ve configured the flexi task exactly as above and run the workflow. When both people approve the flexi task, we get the expected outcome as per the picture below:
However when one person rejects the flexi task, something strange happens:
What on earth is going on here? Why didn’t it execute the tasks in the Reject branch!? The key here is understanding the fine print and I refer to our friendly Nintex User Guide for the exact wording:
All assignees must select the outcome specified in the 'Outcome' drop down list. If any assignee chooses an alternative outcome, all pending tasks will be set to 'not required', the 'outcome achieved' variable will be set to 'no' and the overall task outcome will be blank.
That’s right - what the user guide is telling us is if the people disagree, there is no outcome. It doesn’t default to rejected as you might have suspected. Initially that doesn’t seem to make sense. Surely if the outcome isn’t approved it must be rejected?
The logic only becomes apparent when you have three or more outcomes (e.g. Approve, Reject, Escalate). If the assignees disagreed, how would Nintex know which branch to follow? This is why the User Guide states that the overall outcome is blank. It even provides a method of telling you that no outcome was reached by optionally setting some variables:
With this new found information you can check the status of that outcome variable and adjust your workflow accordingly. There are many ways of handling this depending on your exact requirements. The Run If and Set a condition actions come in quite handy here but I’m sure many of you will have other methods you can suggest.
The same “no outcome” applies for the other behaviours: You will reach no outcome under the following conditions:
Behaviour selected | Flexi task results |
---|---|
Majority decides | A majority is not reached. E.g. there is an equal amount of reject and approve replies |
Majority must choose a specific outcome | A majority is not reached. E.g. there is an equal amount of reject and approve replies |
All must agree | Just one person submits a different answer to the rest |
As long as you are aware of the “no outcome achieved”, your life will be much easier when dealing with multi-recipient flexi tasks.
So what was the final solution for my original example where we have two outcomes to choose from (approve and reject) and if one person disagrees, we should execute the reject actions? We could submit a request to the team at Nintex to create a default outcome field or for the next best thing: include an “other” branch which you will find in the Advanced Options and move all reject actions to this branch. If an outcome is not achieved, the other branch (if it exists) is executed.
Hope this helps!
Cheers,
Chris | Provoke Solutions