Ken Hawkins wanted a specific State Machine solution. For some reason my .jpg file didn't send when I tried to reply through Nintex. So I am creating this post. The question is:
Create a state machine. One of the states will be for the initiator. Depending if the approvals are done separately or all at one time will determine if there are 5 more states or 1. If any of the approvals are rejected, change the state to Initiator and it will go back to the Initiator state branch. Put the logic in there to check that it is rejected and do what needs to be done.
But I'm not clear on how you would set up the state machine for this scenario (new to Nintex and Sharepoint, old NotesDomino developer :) ).
Can you send me an example?
I'm not sure if I completely understood, but here is part of a solution I provided. I left out actions he would need to create and a variable would need to be created so if it was rejected the Initator would no to do something different than the actions when it is initially started. Hopefully this helps.
Solved! Go to Solution.
OK. But how do I get it to pause and wait for the Initiator to "re-submit" the item? I tried setting a variable "resubmit" to "no" initially. Then reset to "yes" as part of the rejection path. The workflow is set to start on either a new item, or if it's modified and resubmit is "yes".
My result is it loops back to Initiator without setting resubmit to "yes", and doesn't wait for the item to be modified (and re-sends the approval notification). I don't think it ever sets resubmit to "yes". I am doing update and commit actions after the approval task is declined/rejected.
Let's see if this is right:
1) Initiator submits item.
2) Any approver rejects item.
3) The Initiator should be alerted.
4) The initiator should re-submit the item to go through the process again.
Is that the correct flow that you are looking for? Would the item be resubmitted to all approvers?
I just want to get the clear path before I comment.
Alright, so by "the approval path is sequential", do you mean that even if Approver 1 rejects it, then Approver 2 still gets a chance to review it? Or would they not?
It sounds to me like you may just want a 2 state machine with a Flexi-Task in it. Need to ensure what you mean by "approval path is sequential" though!
Alright, I think I'm on board now.
Here is how I would handle it:
1) State machine with 2 states: Initiate & Review. (Starting in Initiate.)
2) Under "Initiate", put whatever task is needed to when this whole shindig sets off - maybe it's to notify the Initiator of who the reviewers will be, or how many, etc. Then, a "Change State" to Review.
3) Under "Review", use 1 Flexi-Task.
a) Set to "All must agree on a specific outcome"
b) set that outcome to "Approve"
c) in the very bottom of the options, check "Include an Other branch".
4) Under "Other" and "Reject" (just in case), put in whatever your rejection tasks are. Sounds like it's to set the state to Initiator.
5) Under "Approve", do whatever should happen if all reviewers approve -- maybe it's to have a party or order a cake.
Of note: If your reviewers continuously reject, it's going to continuously go in this circle until they all agree on approval. It sounds like that's what you want.
Resources: Our very own vTE Chris Ben wrote a fantastic blog on Flexi-Task which details why on earth you would make some of these selections that might help you out: https://community.nintex.com/community/build-your-own/blog/2015/01/22/do-you-really-know-the-flexi-t...
Let me know if this is helpful or if you need some more details / examples.
Hi burkslm ,
I have worked on this same scenario. I will elaborate on this , please let me know how far you are OK with my clarification.
1. Use Assign a Flexi-Task for approval process
2. By default Assign a Flexi-Task will have 2 task outcomes namely APPROVE & REJECT.
3.Click on Add outcome and add on-more outcome naming as REVERT.
4.Now you have Assign a Flexi-Task with 3 outcomes . Viz Approve -- will take to process to the next stage of the WF(Change State Action to Next State)
Reject -- will terminate the process as it is.(End WF)
Revert -- Have a Change State Action in this branch , and change the state machine to the previous state.
Hence , at any level of approval the workflow will proceed according to the outcome of the current task. Even in the last Approval Stage if the Approver clicks Revert , then the Task will be assigned to the previous task assignee for review.
hope this helps.
Bashya Rajan A
It looks like Rhia and Bashya have supplied very similar solutions, except I'd suggest that Rhia's is more complete because it handles the case where one user rejecting stops the entire process.
, the initiator would still be expected to go and modify the original item before replying to the task using this method. i.e. "Dear initiator, your submission was rejected by someone because of xyz, please go and correct and let us know when you've done by hitting the abc button".
Alternatively you could modify the workflow to run upon item creation and modification and set a status field. The first thing it does is to check the status field to know what state to start in.