Task will end on first rejection

Steve,

Why don't you make use of "Majority must choose a specific outcome" or "All must agree on a specific outcome" behaviors.

You can define the outcome under "Choose an outcome configured for this task" drop down.

Cheers!

Shreedhar H V

As Shreedhar HV​ mentioned above, I would look into utilizing the different behaviours that are available in the Flexi Task action.

I would lean more towards "Majority Decides"; this will allow the task to go in either direction rather than forcing them into a specific direction.

Now in regards to having the ability to see everyone's decision, you would have to lookup each user's task and evaluate that.

Hi Shreedhar,

Thanks for your advise, i tried the "Majority must choose a specific outcome", it not work for me in some case. let's say we have three participants, and the"All must agree on a specific outcome" i choose "Approve", if the first two participants reject the task, the task will reject and the third participant will not have chance to approve or reject the task it will set to 'not required'. What we want is if one of the participants reject the task, the whole task should be reject not all participants should have chance to vote and comment.

If i was wrong please correct me, thanks.

Hi Jesse

Thanks for your reply, but for my case even the majority decision is approve but one of them reject the task, it should be reject.

Ok so you want everyone to make a decision and then if someone rejected it, the outcome is rejected, that correct?

Yes, correct.

Steve,

Please go through the link Build a Better Nintex Workflow “Assign To-Do Task” Form | TechRhodes

I hope this is what you are looking for!

Cheers!

Shreedhar H V

I would approach this with a State Machine (check out this blog if you have any questions around that Using State Machine Workflows).

At a high level, this takes the approval out of tasks and puts it in the item on the list by adding a column of "status" and "final_status" and having users update those fields. The workflow looks for changes and then logs the changes. Now keep in mind that I left out the logic around what you want to do for each (meaning what happens if it is approved or rejected? Are there more steps? Are there notifications?), but you can inject them where it makes sense to you and fits your needs.

The workflow (action sets are minimized so you can see it):

Pending:

The workflow is triggered when a new item comes into the list and enters the state machine as 'pending'. The workflow then waits for an update to the status field and assesses the change (approve or reject) and changes to the proper state.

Approve:

if 'status' = 'approve' then we log it (I simply put a Log to history action but you could write to a list or do whatever you want). After we log it, update the status back to pending (for the next approver) and update the 'final_status' if it is not already rejected. Once this is done, we simply change back to the 'pending' state and wait for another change.

Reject:

Again, if 'status' = 'reject' we log it, update the status back to pending (for the next round) and then update the final_status to be reject (since if anyone rejects it, it is marked as such).

Now keep in mind you will need to account for a few things:

1. Who can approve, how do you make them take action (since there is not a task associated)

2. How do you end the state machine (can be solved once you get the rest).

Here is my thoughts for what it is worth:

I would setup a SharePoint user group that had the ability to approve and then send them a notification with an edit URL to the item. In the state machine I would increment a variable each time its been reviewed (numOfApprovals) and once it is equal to the number of users in the SPU group end the state machine. This may require some web service calls to the usergroup.asmx and use the GetUserCollectionFromGroup method, but can be done.

Long winded, but I hope it helps!

Jesse

Thanks for your advise, it might be works. but too complex. We have lots approval stage needs that function,it will make workflow more complex and heavy, regrading this stats machine and waiting for change function, i used it before and the wired thing is sometimes it will stack in pending even the users has finished their task. and it will affected the other state machine until i end the workflow and restart it. it really wired, so i don't prefer to use too many stats machine and waiting for change function in our workflow, but thanks anyway.

hmm, interesting article but the question is how to retrieve the data from "assign To-Do Task" and show into the workflow history.