The Flexi task is one of the most popular workflow actions. It’s always in the top five when I run “know your workflow” analysis for my customers.
How much of it do you really know? How many of the options have you used? In this blog post series, we’ll cover how this task works.
This post will cover behavior. I’m going to provide examples of the SharePoint on-prem version. Many of these concepts also apply directly to the SharePoint online “Assign a task”, “Start a task process” and the Nintex Workflow Cloud “Express approval” actions.
So, let’s get started with the behavior section:
What do these options actually mean?
Often we accept the default behavior “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. But things get a little trickier when multiple people are involved.
In our next example, the Flexi task has two outcomes (Approve and Reject) and is sent to two people. In order for the task to continue, we want both people to approve it. If either rejects the task, we want the workflow to manage the outcome as if it was rejected. Simple enough, right? 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 shown here:
However when one person rejects the Flexi task, something strange happens:
It didn’t execute the tasks in the Reject branch. Why? The key 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 – the user guide is telling us that 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 becomes apparent when you have three or more outcomes (e.g. Approve, Reject, Escalate). If the assignees disagreed, how would the workflow 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 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 specific 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 to suggest.
The same “no outcome” applies for other behaviours – you will reach no outcome under the following conditions:
So what was the final solution to 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 Nintex team to create a default outcome field, or 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.As long as you are aware of the “no outcome achieved,” your life will be much easier when dealing with multi-recipient Flexi tasks.
Hope this helps!
In the next blog post we cover reminders and escalations. Check it out!
