Hi @JosephBooth 

Unfortunately "Assign Flexi Task" doesn't have that behavior - "all assignees must respond"

Refer to the help reference at https://help.nintex.com/en-US/nintex2016/current/sp2016/Workflow/ActionsCore/FlexiTask.htm 

Hi @JosephBooth 

In your workflow process, is the list of assignees fixed or dynamic?

Fixed - exactly 5 assignees each time.
Dynamic - (min 1, max 8, assignees depends on Initial Form values.

Is the Task order independent (a.k.a no specific order) of each other?

If (Fixed and Is Independent), then you can use the Parallel action with Flexi Task in each branch.

This way, will allow for the usage of Flexi Task and All Assignees must respond however you will need to keep track of the combine outcome.

If (Dynamic and Is Independent), you can use the Parallel action, but certain Flexi Task must be nested in a Run If action. Again you will need to keep track of the combine outcome.

Cheers

I have a dynamic number of reviewers any time the workflows are run. Yes. I have many of these types of workflows in my site collection. It could be one person or fifty people or even more. My org has 10,000+ employees.

Using the parallel action technique requires constant upkeep to make sure that any group within the site collection doesn't outgrow the number of branches in the solution.

Right now, I'm leaning towards building out each part of the functionality that the "Assign Flexi Task" action provides into different workflows on my task list.

My current thought is: get members of sharepoint group (Call Web Service action) into a collection variable, use "for each" to create an individual task for each member, use list workflow for email notifications to assigned reviewer, use list workflow for any reminders, use list workflow for escalation if past due date, use list workflow for delegation and use list workflow when approve/reject is selected.

Which is alot of work and documentation of all these moving parts will not be fun.

I hesitate to build a solution using parallel actions. Every time I need to make a change to wording in an email notification. I could - potentially - be editing many, many copies of email body, subject lines and all that.

I mean... if I'm understanding this correctly. The solution of using run parallel actions... if I had 100 people, would require me 100 edits to an email message or update to an escalation condition or any small tweak that I make to one "Assign Flexi Task" I would have to go into each of the other 99 to make too.

Or I'm making variables for all of the message elements (probably losing the ability to style the message using CSS) and number values... etc. And then managing that.

All of which I need to document completely for the next person who sits in my seat to even begin to remotely understand what the heck is going on with this workflow.

That sounds horrible too.

Thank you for taking your time to provide me with information about this action @Garrett. It is appreciated.

I'm not 100% certain which way I should attack this problem.

Hi @JosephBooth 

A most unusual but rather interesting dilemma. Let break down the problem into smaller bite-size issues and find possible solutions.

1. Get Assignees into a Collection Variable.  

     You seem knowledgeable on this matter.

2. Use a For Each Loop (with the Assignees Collection variable)

2.a Start Workflow - call the site workflow which has the Task Assign 

Place the Task Assign inside a Site Workflow.

You will pass the 1 Assignee email to the Site Workflow.

Now you only need to manage a single Task Assign (and not 100 Task Assign)

Would this work for you?

Now that's highly interesting @Garrett!

I assume that I'm using a Nintex action to pass the email address and any item properties needed from the document library workflow into this new "site workflow" to handle task assignment?

Is that possible?

Hi @JosephBooth 

Start Workflow 

https://help.nintex.com/en-US/nintex2016/current/#sp2016/Workflow/ActionsCore/StartWorkflowAction.htm 

"The Store data and Retrieve data workflow actions can be used to transfer values between workflow instances. A workflow that is started by the Start workflow action can store a value with the Store data action, and the parent workflow can later retrieve that value with the Retrieve data action and the value stored from the Store Instance ID in option."

Store Data

https://help.nintex.com/en-US/nintex2016/current/sp2016/Workflow/ActionsCore/StoreWorkflowData.htm 

Retrieve Data

https://help.nintex.com/en-US/nintex2016/current/sp2016/Workflow/ActionsCore/RetrieveWorkflowData.htm 

I got this working yesterday. Very cool. I have a file that I'm keeping my notes in and will post to this thread once I'm finished.

For anyone that comes across this in the future.

Using "Start workflow", "Retrieve data" and "Store data" actions to pass values between two workflows is very handy. Not entirely clear through the nintex documentation on how to set up all the moving parts to make it happen.

This page was helpful: https://community.nintex.com/t5/Community-blogs/Using-the-Store-data-and-Retrieve-data-actions/ba-p/83196 

I had to read it many times and work slowly to figure it out. You may have an easier time with it.

Heavy use of the "Log in history list" action to print out the variables and parameters to the history list is required during the learning process of this technique.

The basic idea is to have a parent workflow call a child workflow. The parent will use the "Start workflow" and "Retrieve data" actions. The child will use the "Store data" action and you can use as many of these as you need for the values you need to pass.

• Parent Workflow Use Actions:
  
  
  
  
  
  • Start Workflow
  
  
  
  • Retrieve Data
  
  
  
  
  
  



• Child Workflow Use Actions:
  
  
  
  
  
  • Store Data
  
  
  
  
  
  

Most importantly, after you setup the "Store data" actions in your child workflow - publish it. When you do this the variables you configure for "Store data" will appear in the "Start workflow" action and this is where you identify what item properties you want to pass.

For your variables in the child workflow. Check the "Show on start form" box so that the "Start workflow" action will actually display the fields needed to identify the values you want to pass to the child workflow. Otherwise, you will setup your "Store data" actions and not be able to pass the values from the "Start workflow" action.

This was challenging to setup. There is certainly an opportunity for Nintex YouTubers to make a training video for this technique.

So far, the workflow allows me to create individual "Assign Flexi Task" items for each member of my SharePoint permission group. One reject does not kick off the no longer required action. This is great.

This method of having the task outside of the parent workflow does mean that I've lost the "pause workflow" while the flexi tasks are running feature which is built into the action. So, now I'm going to have to come up with a way to have my parent workflow wait until all of the processes on all of the assigned tasks complete to move forward in the flow.

It seems like it would be so much more convenient if the "Assign Flexi Task" action had a behavior "All must respond". 

Thank you @Garrett for pointing me in this direction. Early sense is that this will get me to where I need to be with my solution.

You're most welcome @JosephBooth 

Glad that you got a working solution and thanks for sharing your findings. 

Yes, the Log to History is the best developer debug tool. Log to History will truncate chars after 256 chars, so make use of Send Email to get the full message.

Also, I suggest to hardcode values (parameters) when you are trying out new new action. Once you get the action working, then replace with variables.