Error Handling with Nintex Workflow
Table of Contents
Following my previous post about developing top down workflows in Nintex. I thought it would be useful to continue with a post about error handling in Nintex as I’ve been implementing workflows while working as SharePoint consultant.
When workflows in SharePoint error, the workflow is still seen as an active workflow. Not until the workflow is terminated it’s marked as cancelled and therefore finished workflow. While there is a workflow instance active it will not be possible to start a new instance of the same version of the workflow. This can be quite annoying as cancelling 100 workflows, fixing the workflow in Nintex Workflow Designer and then restarting the failed workflows only can be quite a task.
So in short it is better to avoid workflows with and error status.
There are a number of ways to avoid errors or recover from errors in Nintex.
- Include an error state in a state machine
- Avoid the activities failing
- Enable error handling in each activity
- If things do go wrong make sure that you can recover.
- Avoid If use Set condition instead
Include an error state in a state machine workflow
As described in my developing top down workflows in Nintex post I always use state machines for all my workflows. One of my states I call “Error” so that when unexpected values appear in for example a switch I’m changing my state to Error and send out an alert email to myself. Using this additional state avoids a repeating set of activities throughout my workflows.
Additionally error handling tends to clutter the workflow logic. Having the error handling no-code separated into it’s own state makes the logic of the workflow clearer to understand.
Avoid failing workflow activities
Some workflow activities generate critical error and make a workflow fail. Before running these activities checks should be run to avoid failures.
Some examples of failing activities:
Request Approval
When an approval request runs and the approver field is empty then errors will occur. Typically an Approval Request is called using Nintex Workflow Variables where a variable contains the person that needs to approve the request. So before running an approval request the variable should first be checked.
Update Item
When updating an item either with the update multiple items or update item activities, workflows can sometimes fail. It’s not always easy to identify why. Quite often I found the SharePoint ULS logs giving some clues. Most of the time I’m simply updating and item without one of the required fields being set or sometimes trying to push some text into a number field. Again some checks before hand would be a good plan.
Enable Error Handling
Some activities have Error Handling available. on of these activities is Create Site Collection.
Unfortunately not all activities have this error handling available.
When it is available however it’s easy to use a Set Condition activity to check if the operation was successful or not.
Recovering from critical error
Ok, so now it’s all gone wrong and we need to fix the workflow and restart the workflows however we do not want to go through the first 9 out of 10 approvals again. We simply want to restart from the point the workflow got to earlier. This can be done by adding an initial state that includes a switch
Conclusions
Error handling is important and can be difficult. Ideally I would like to enable the error handling option for each activity (if it only existed).However with the above ideas I’m getting close to error free workflows.