Error Handling with Nintex Workflow

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 at Triad 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 inot 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.

NintexRequestApproval

 

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.

ItemUpdate

Enable Error Handling

Some activities have Error Handling available. on of these activities is Create Site Collection.

ErrorHandling

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

ProcessRedirect

 

 

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.

 

Advertisements