chris.ben

The magnificent Flexi task: Behaviour

Blog Post created by chris.ben Champion on Sep 8, 2017

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. Hope you you find it helpful!

 

This post will cover behaviour (or, for those of you who speak North American'glish, behavior ;-) ). You may have seen an article similar to this titled "Do you really know the Flexi task?" Yes, the two are almost identical, but in this series we'll show you every feature of the Flexi task as opposed to the previous overview.  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 behaviour section:

 

What do these options actually mean?

Often 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. 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:

Behaviour selectedFlexi task results
Majority decidesA majority is not reached, e.g. there are equal numbers of reject and approve replies
Majority must choose a specific outcomeA majority is not reached, e.g. there are equal numbers of reject and approve replies
All must agreeJust 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 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.

 

 

Hope this helps!

 

In the next blog post we'll cover reminders and escalations.   Check it out!

 

Cheers,

Chris | Provoke Solutions

Outcomes