Nintex Workflow – Smart Restart Workflow (middle of a workflow)
Many people have asked “If a workflow fails, or I need to restart it for whatever reason, can I get it to start at a specific action?”. The answer is usually, “This is not easily possible and you would encounter the same issue if you were using a SharePoint Designer workflow.”
So what is so difficult about getting a workflow to start at a particular point?
The answer is, it really isn’t. It just requires a little more thought about how you design your workflow.
I propose the following situation :
I need a workflow that will go through 4 levels of approval before a project gets completely approved. The 4 levels include :
1. the workflow Initiator’s Manager
2. the Executive Manager
3. the Chief Financial Officer
4. the Chief Operating Officer
It must first get approved by the lower pay grade employees, before moving up the chain. If at any stage, and approval gets rejected/declined, I need the Initiator to be notified, and the workflow to end.
In this situation, it is my experience that if there is rejection, then it will mean a lot of work that needs to be done by the initiator, which could span weeks or months and I don’t my workflows to linger while this happens.
The caveat here, is that if we get all the way up to the Chief Operating Officers approval and he/she rejects it, then when I resubmit the project, I don’t need all the other people to approve it, I just want the CEO to approve it.
Solution
The main part of the workflow needs to be the State Machine. You can do it other ways, but this is definitely the most logical and also the more pleasing to the eye and the brain (who needs more headaches?).
The other important factor, is that we need to store some information somewhere so that when the workflow starts, it can read that and know what it needs to do. For this, I have chose to create a hidden field in my list called “MyInternalWorkflowStatus”. My workflow hsa 5 states in the State Machine :
1. Initial – where all the initial processing/logic is done.
2. Manager Approval
3. Executive Manager Approval
4. Chief Financial Officer Approval
5. Chief Operating Officer Approval
That’s the workflow. Doesn’t look too hard or too complex does it? (shhh that’s the beauty of Action Sets. If you don’t believe me, click on the link.) Time to look a little deeper. The first state “Initial” will read my “MyInternalWorkflowState” field and store it in a Nintex Workflow variable.
Then, we use the Switch action to perform different logic depending on what is in that variable. If the value is nothing, as shown with the switch value “Other”, then we jump to the Manager Approval state. On the other hand, if the value is “Manager Approval Done”, then we jump to the Executive Manager Approval state.
So you can see here, that depending on this value in my field, my workflow will do the appropriate logic. If the manager has already approved the project, but the exec manager rejected it, the value in the field will be “Manager Approval Done”. The next time the workflow is run, it will recognize this, and bypass the Manager Approval state, and go directly to the Executive Manager Approval state. This is what the Switch action configuration looks like :
For the purposes of this article, the other states are mostly the same, with some minor changes to store the correct state information in my field. Here is an example of the Manager Approval state. Again, this was kind of hidden by the fact that I put it all in an Action Sets an minimized it.
The approval states simply send out a Request Approval and if it is rejected, it notifies the Initiator, and then exits out of the State Machine (in this example, ends the workflow). If it is approved, then the field “MyInternalWorkflowStatus” is set to the appropriate value. eg. for a Manager Approval, it sets it “Manager Approval Done”, of the Chief Operating Officer, it’ll set it to “Chief Operating Office Approval Done”.
What happens when this runs?
To see if the workflow runs as expected, I run the workflow and the Manager approves the project, but the Executive Manager rejects it.
From the graphical view of the workflow, you can see that everything is green, and the workflow is complete. It got to the Executive Manager Approval state, when the rejected the project, the Initiator was notified, and the workflow ended nicely. Imagine weeks later, the Initiator makes the appropriate changes, and restarts the workflow.
You can see from the above graphical view, that the workflow started, went into the Initial state, and then jumped directly to the Executive Manager Approval state, completely bypassing the Manager Approval state as it is already done. Now, all the other people approve the project, and the resulting graphical view of the workflow is this :
All the states are complete (green), except that Manager Approval state, because that was completely in the previous instance of the workflow.
Conclusion
Now most business requirements will be more complex than the scenario shown above, but atleast this should make you think that just because the SharePoint workflow engine doesn’t have the ability to start a workflow at a particular point, there is no reason why you can’t be clever in your workflow design to accomplish the goal that you need. When you are in the Nintex Workflow designer, remember, you don’t just have the actions available to you, but you have the SharePoint item the workflow is running on, other lists of data, web services (not only SharePoint), a huge arsenal of tools at your finger tips. You just need to take a step back and draw out a plan of what you need, and how you can acccomplish it.
Files to Download
This workflow needs a new field in the list you import it into. It is a Single Line of Text and it is called “MyInternalWorkflowState”.
