11

Environment: 2013 Enterprise, Workflow Server on WFE, SPD 2013

This seems like a pretty simple question coming from a programming background, but I just can't find any information on it. When building workflows in SharePoint Designer, how do you handle errors? From what I can tell, if a workflow fails, your only option is to manually catch it, cancel it, and erase any bad data it may have already committed. Obviously workflows should work flawlessly, but any programmer knows there are always exceptions you can't account for. Is there some way to catch exceptions, or trigger another workflow when one fails that can do damage control and make sure the system continues operating smoothly?

For example, I have a list with items that are worked on by multiple users, and they input temporary values into some of the fields for certain calculations. There is a workflow that triggers when the items are changed and reads those values, does the calculation, then blanks those fields so the next user can put new values into them. If for any reason the workflow fails, the fields retain their values and no more users can input new values until someone notices the failure, cancels the workflow, and manually resets all the fields. What I want is to have a way to automatically catch those failures and make the corrections on the spot so there is no interruption in business.

Where's a TryCatch block when you need one?

  • what does your workflow do? – Mike Dec 12 '13 at 16:42
11

Based on your question, there are two areas to address:

  • How to help your particular problem
  • How to handle workflow errors in general with SPD

For your particular problem:

I see something that may improve your process based on your description. You mention your general workflow as the following steps:

  1. item changes
  2. workflow reads fields
  3. workflow does calculation (error prone)
  4. workflow clears fields

Your issue is if the process errors out in step 3, the fields never get cleared. What if you assigned the fields to temp workflow variables and then cleared them out before your calculation?:

  1. item changes
  2. workflow reads fields and assigns each field to a temp variable
  3. workflow clears fields
  4. workflow does calculation using temp variables (error prone but fields are already cleared)

General SPD Workflow Error Handling:

As there is no try/catch in SharePoint Designer workflows, you must learn to use the history logging mechanisms to your advantage. I have had workflows where each 'work' item is followed by a 'log' item to the workflow history table. Each log entry has a sequence number as part of the log string. This allows me to go in and easily see exactly where a workflow stalled for any given individual workflow. If there are troublesome areas of your code, you can use an 'if' in the workflow to verify that a particular variable is not null, is not empty, etc. You can then branch to a log statement that ends the workflow if your variable check fails, but allow the workflow to continue otherwise. Think of it as having many 'asserts' in your workflow.

Even more powerful is the ability to set alerts on the workflow history tables.
This mechanism is described in detail by Dave Sampson at this link (http://dave-sampson.blogspot.ca/2012/06/simple-sharepoint-2010-workflow-error.html). However, in case the link eventually goes away, I will give a quick summary of his tips:

Unexpected errors are logged to the workflow history table with an eventcode of 0 or 10. You can set a custom view up on the workflow history table to only show these error condition items. You can then set an alert to trigger when an item is added to that 'error view' to alert you. In this way, you can be alerted whenever any unhandled errors occur in your workflow. Best practice at that point would be to determine any error handling logic that could have prevented said error, and add it to the workflow. In addition, you could use your own 'logging conventions' in your workflow history logs to identify cases where your workflow 'asserts' failed. For example, if all of your assert log entries started with 'ASSERT FAILED', you could create a view (that only shows items where message starts with 'ASSERT FAILED') and set a custom alert notification based on that. Using these conventions, you could be as general or as granular as you need.

Hopefully this gives you some new ideas on how to get better insight into your SharePoint workflow errors.

  • That's exactly the kind of answer I was looking for, wish I could give it two votes, thanks! That puts everything in perspective with the code logic I'm used to, and the logging method is wonderfully simple and flexible. – thanby Dec 13 '13 at 13:56
  • 2
    You're welcome. Coming into SharePoint as a seasoned developer is a jarring experience to say the least. For everything you are used to doing, you must identify 'the SharePoint way' of doing the same task. – tyshock Dec 13 '13 at 15:32
1

I can't comment on the above answer but this won't work on 2013 workflows as the information needed isn't captured in the workflow history list.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.