Skip to main content

I have a requirement to have 12 stakeholders indicate their approval via lazy approval - as long as none reject and doesn't matter how many actually approve, after 7 days, we want to automatically end this approval task and move to next level of approver and change the unanswered stakeholders' status to "No response".  At any time we do want to see which of the 12 stakeholders have approved it on a SharePoint site displaying the status. 

Should I still do a SharePoint group with the 12 users with "all approve" and a "timer" action or do a "support list" that assigns a flexi-task to each of them and run them parallel?  When I did this 2nd option before it seemed to create errors on the workflow when the multiple approvers responded so I'd have to end the workflow and then restart which would then cause confusion among those who had already approved.  TIA!

Any advice as I need to get started working on a solution and would like to do "best" way first time!  :-)  TIA!


I would go with the 12 tasks in parallel. Can you give some more info on what went wrong last time? I'd have each task have 3 options: Approve, Reject, No Response. Have an auto-complete after 7 days that auto completes anyone who hasn't responded to "No Response." Did you have a variable for your parallel branch to complete on? 


Thanks Courtney!  It was a few years ago when I did something like this but I just remember each time 1 or 2 branches would receive errors and in order to try and get those approvers and the ones still outstanding I would have to re-start the workflow which created confusion for those who still needed to approve that didn't get the error. 

What do you mean on the "variable for your parallel branch to complete on"?  If I remember right I did a counter of sorts where each time one completed I updated a number field by 1 so when it reached 12 it moved to the next step which was another approver level. 


You can create your parallel block and in the configuration for it is an option to basically have a variable that will trigger exiting the block even without all branches having finished. In your case, it seems like all the branches would finish because you'd have them auto-complete after 7 days. But, if you just wanted to exit the parallel block, you can have a "set variable" action at the end of one of the branches to effectively end the block without allowing the other branches to complete.

But you don't need all of them to approve, right? Just at least one, really, right? So your best move would be to wait for all branches to complete and to use the auto-complete function of the task.


Oh no we do want all 12 to approve!  If one rejects then it ends the workflow completely. 


"as long as none reject and doesn't matter how many actually approve"? If someone rejects, it ends, but if, at the end of the 7 days, 4 people have approved and 8 haven't done anything, it should continue to the next level, right? That's what I understood from your original post.


That's correct!  We'd like all 12 to approve but if only 4 people approve, none reject and 8 have done nothing, then it can move to the next level.


So, I would assign all 12 tasks in parallel. On each task, have it auto-complete after 7 days to a "No Response" branch. If anyone rejects, the workflow terminates. By having the auto-complete, your parallel actions will all execute and advance to your next workflow piece which will be your "next" level of approvers. 


OK thanks I will try that!


OK so I tested this with 3 approvers - 1 approves and is fine waiting on others.  Once the 2nd approver replies approve or reject, it cancels the workflow and states "The task is no longer active. Another user may have already completed the task." I've attached a screenshot of the workflow with flexi task for 3 approvers.  Parallel action with 3 approver branches with flexi-task assignment


Hmm, why does FlexiTask 2 look different from the other two tasks? Are its branches further down? I've not seen that in 365 (we just have "assign a task" action and the workflow just widens to show all ).


Oh I just minimized it since it's the same as 1 and 2!


Ahh, I don't think I have that magic in 365 either! In any case, are you able to see the tasks in a task list and verify that a separate one is created per flexi task assignment? Can you log the IDs of the created tasks to verify that separate ones are created? Also, it may help to have a pause for every other creation possibly?


Yes it does assign different tasks for each altho right now it's just me for all 3 tasks.  Screenshot showing individual tasks assigned


And for grins, I tried with another approver other than me and workflow still cancelled on 2nd and 3rd approvers that were still outstanding!  :-( 


Hmm, why not use this action: Assign To-Do Task 

This part of that config is particularly interesting: 

Create individual tasks for all group members

In the case when a group is assigned the task and Create individual tasks for all group members checkbox is:
  • not selected, all users in that group will receive the task notification. The first respondent will represent the entire group.
  • selected, an individual task will be assigned to every member of the group. 

Hi Kim Nickles‌, if you are still exploring different approaches to accomplish this, I just posted something that worked for me.  It might give you some ideas: Blog post: Rock the vote!


Thanks Brian!!  Very detailed and informative!!  On your parallel flexi tasks, are yours not cancelling the others out when another branch replies as that's what happened with mine.  First approver went thru fine but once the second one replied with lazy approval it errored out and cancelled all the other tasks!  :-(  I'm now doing individual workflows for the 12 approvers. 


I need to be able to use lazy approval so can't use Assign-To-Do task.  But thank you!!


Hi Kim, the main reason I went that route with the parallel tasks was to ensure that they did not cancel each other out.  The request from the process owner was that all voting parties would have an opportunity to respond until the due date and time was reached.  So, using the parallel structure, the flexi tasks don't interact with each other... any number of people can respond approve or reject, or not at all, and everything is counted up at the end with the tally.  Hopefully I read your question correctly...  Please let me know if you have other questions.


Brian - yes I tried to use the parallel tasks so as long as one didn't reject, the others could still approve their tasks.  However, after 1 is approved, the workflow is cancelled when the 2nd approver tries to approve or reject.  My branches do update fields for either approve or reject so maybe that has something to do with it.


Hmm, there must be something different in the configuration of our tasks because mine will keep those other tasks open.  Each of my tasks are assigned to one SharePoint group, and each group just has one member.  Are yours set up that way?  Also, your theory about the field updates might have something to do with it... maybe you can save the values to variables and move those updates to later in the workflow or just disable them temporarily to test it out.  In my workflow, I have some updates to the item to record the number of all the yes, no, and no responses which happens later.

Here is a screenshot of the workflow history for an item in my list that has a due date and time of today at 5:00 pm.  The marketing one was responded to with "Approve", Accounting and MCSO responded with "Reject", and the others haven't responded, but they will remain pending until 5:00.

parallel tasks

It definitely works, for these items.  I think I put all of the configuration settings into that blog post, but I can check on anything in there to make sure yours are set up the same way.  

task config


If you are going to do multiple parallel approvals, I would advise against starting all at the same time - I have had bad experiences with multiple (10 or so) parallel dept approval processes starting at the same time - the workflow engine gets overloaded - so best to add a few 'wait for duration' actions delaying approval tasks so they start in staggered starts of around 3 or so approval tasks.


That's a great tip!  What kind of issues were you seeing?  Thanks!


Reply