Skip to main content
Nintex Community Menu Bar

So I have had this blog post on my "to do list" for some time now and the list is now beginning to get scroll bars so I have to tackle it!  I have seen a lot of questions posted on the community (and asked in my workplace) about workflows incurring an error without much detail as to why this has happened.  The thing that I would always offer to anyone with these problems is to use the inbuilt error handing within Nintex workflow actions wherever possible.  Why?  Well a number of reasons actually:

  • If a workflow errors it notifies the initiator (unless those settings are changed).  Normally the initiator is a user in the business unaware of the design of the workflow, and sometimes unaware of the workflow altogether.  The last thing these users want is a ghastly email that says a workflow, that they may not be aware, has errored with some hideous details that they don't understand:

200175_pastedImage_1.png

  • The details given when a Nintex workflow errors are sometimes completely non-descript and offer no help or direction in where you, as the workflow developer, should look to find the issue and resolve it.  An example of this helpful error is here:

200289_pastedImage_1.png

  • OK sometimes errors in the workflow are the end of the world(!!) and will mean that the workflow will need to be terminated and started again.  However, sometimes, an error in an action wouldn't mean the end of the world and you might be happy to just catch and log the error without having to visit the workflow on the item, terminate it and restart it.

 

Actions with Error Handling

My understanding of the Nintex workflow actions is that the following all have error handling in their configuration (please correct me if I have missed any):

  • Call web service
  • Execute SQL
  • Find users by status
  • Get user status
  • Query BCS
  • Query Excel Services
  • Query LDAP
  • Query XML
  • Update XML
  • Web request
  • Convert document
  • Copy to file share
  • Copy to SharePoint
  • Create item in another site
  • Create list
  • Delete multiple items
  • Submit record
  • Update multiple items
  • Convert value
  • Add user to AD group
  • Create AD group
  • Create AD user
  • Create site
  • Create site collection
  • Decommission AD user
  • Decommission site collection
  • Delete AD group
  • Delete site
  • Enable Lync / OCS
  • Provision user in Exchange
  • Remove user from AD group
  • Update AD user
  • Create appointment
  • Create task

 

Configuring error handling

All of the above actions have in-built error handling available in the configuration of the workflow actions.  Error handling looks like this in the workflow action:

200290_pastedImage_4.png

By default it will be set to capture errors = No.  You have three choices here if you want to catch errors:

  1. catch if an error occurred:  "Store error occurrence in"  a simple Boolean value that will indicate if an error occurred in the execution of the action.
  2. catch the details of the error:  "Store error text in" a text value for the error returned in the execution of the action
  3. catch both (my general approach)

So to use these options you need to create some variables to store this information.  I normally create a Boolean (yes/no) variable and a single line of text variable and configure my error handling as follows:

200306_pastedImage_5.png

200307_pastedImage_6.png

 

Note be sure to change "Capture errors" to Yes.

 

Dealing with errors

Well this is a very personal thing and entirely depends upon the design of your solution as to whether the error is a deal breaker or just something to be made aware of.  Generally if it's not a big deal I have a piece of my workflow directly after the action as follows:

200308_pastedImage_8.png

This way the workflow will continue but I will be notified of the error returned.

If it is a deal breaker error, I would normally add an "End workflow" in that "Run if" after the email.

 

Workflow error notifications

By default the initiator will be notified if the workflow errors and has a status of "Error Occurred".  If this is not acceptable to you (which it never is to me), you can change these setting by navigating to Site Settings > Nintex Workflow > Workflow error notifications

200312_pastedImage_12.png

Here I would change "Send notifications to the workflow initiator" to "No" and specify alternative email addresses to be notified instead.

200313_pastedImage_13.png

 

How do you deal with errors?

I am interested to hear from you guys...  how do you deal with errors?  Do you use this built in error handling functionality?  What do you do when an error occurs?

For simple workflows I like the way you described using the run-if block. If the workflow is a little more complex I prefer to use a state-machine with an "error-state". This way I would jump to the error state whenever an error occurs and take whatever measures are appropriate.

This way I dont have to repeat myself after each action that could cause an error, but instead I have a single error handler.

I guess you could even outsource that to an UDA to make errorhandling consistent across workflows.

Cracking idea re the state machine!!

Well, and the UDA. To be continued I think!

‌, at one hand interesting idea, at the other I wonder how do you deal with scenarios when you have several actions with error handling within a branch.

do you branch or run-if after each one to make switch state immediately after error? might make workflow quite bloated and hard to understand.

do you store errors into a collection and process all of them at once?

do you switch to error handling state just for critical errors from workflow logic point of view (like you do not get data you expected and so it doesn't make sense to continue with workflow)?

any other approach?

in either case you need certain handling after each action. simple or not so simple one. but that one still needs to be duplicated.

still run-if + notification sounds to me simplest and clearest approach.

would you share your approach.

I still vote for adding Try/Catch/Finally blocks.  They could be much like Actionsets - drop actions into them, and catch errors that result, and do something, even if that means ignoring the error.  

‌ I swear on my kids lives I didn't see your blog on this from 2012 when I wrote this!! Great minds ay - think we wrote the exact same thing!

Nothing wrong with having two good reference sources available!

Love it!!

Well, it depends. Usually you'll need to handle errors right after they occurred. Either you send out a notification, you switch to another branch or you add some kind of compensation. You figured this already.

My approach in respect to handle "unrecoverable" errors with a state-machine and a special state is, that I don't have to repeat as much as I would need to, when I would add notifications in each "run-if" block. Instead I populate a variable with a (human readable und understandable) "reason" what might have gone wrong, then switch to my error-handling state and then have the state send out the notification to the initiator with the reason and maybe send out another notification to the process-owner. Also I would terminate the workflow, so I can restart the workflow without having the need to terminate the workflow myself.

I haven't though about "collecting" errors, but that's an interesting idea. However I guess, that when an error occured the workflow will not be able to complete, so I don't see any point in continuing the workflow. Even worst: if your workflow cannot "resume" then any additional thinks that may happen in the workflow will be executed again, once you "repaired" the error and re-started the workflow.

thanks for explanation.

I thought it will not be so straightforward...

I'm fortunate that I am directly responsible for two major forms and workflows and I know them best so I updated the 'Workflow Error & Cancellation Notification Settings' and entered my email address in the 'Specify other email addresses that will receive the notifications' text box; therefore, all of the errors are sent to me. That allows me to troubleshoot them, tweak the forms or workflows if necessary, and use it as a "teaching  moment" if the issue is user error.

Hi Cassy Freeman‌,

I have 2 additions:

  1. When error handling is activated (Capture errors = Yes), the visualisation of the action when executed will shown green even if there is an error. This can be confusing for users because all actions are green but still an error occured. The column holding the status of the workflow will also show 'Completed' instead of 'Error occured'. Confusing...
  2. The value in the field 'Capture error' can be based on a variable. When you base this variable on a constant at the site, you can switch error handling on/off outside your workflow (I like putting configuration variables outside my workflows).

Cheers,

Rick

Hi Cassy,

I have a problem in opening Nintex form for Nintex Workflow in one site collection. It opens in other Site collection but, not in that particular site collection. I have done deactivating and reactivating the feature but, still problem not get solved. What can I do?

Hi ‌ can I suggest you ask a new question in the ‌ space where more people will have visibility and be able to offer advice?

Hi Cassy,

Thanks for a nice article, Please let us know if there are any PnP/Best practices/steps to capture unknown errors?

Hi satish - can you expand on the unknown error please? 

Hi Cassy,

These are the intermittent errors occurring in our SP 2013 system consistently, Any help will be appreciated.

Error #1: "An error occurred in workflow 'Workflow Name' "

Error #2: "The workflow could not update the item, possibly because one or more columns for the item require a different type of information."

ThanksSatish

Ahhh those lovely messages!!  no unfortunately not.  The most I do with those is have a look at the history of the workflow to see if there are any actions in the workflow with the error handling capabilities and ensure I use them.  Besides that I make sure the error notifications come to me and not the initiator.  I am not at my computer to check but I am pretty sure you can view the workflow history of the errored workflow and create a case from there for Nintex support to investigate? 

Error 2 would normally imply a mismatch of data or I have seen it when permission changes have not been processed in the order you placed them in the designer. Have you seen this blog post? ‌

error #2 use to happen as well when SP is under heavy(-ier) load.

if you simply rerun the workflow in such cases it successfully goes through

Both Error#1 and  Error#2 runs fine when I terminate the error ones and rerun again, this issue are so sporadic in nature, which is the reason why not able to pinpoint the exact issue. 

Thanks for reply and suggestions

-Satish

Thanks for your post; it has been a source of inspiration. I'm also chasing mysterious workflow errors over on this post: https://community.nintex.com/thread/19927-intermittent-errors-updating-list-item-and-setting-permissions

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings