Customized Workflow Error Handling
Workflow actions can cause errors from time to time. From the occasional email error to Internet outages to documents that don’t exist, issues can and will arise. Most of the time you want the system to stop the process and log the error if there is something that happens. But other times you may want to let the process continue, or to use “customized workflow error handling” logic. This article explains how you can do that. The same techniques work in Add-Ins and Action Sets as well.
Default Error Handling
DocMgt has a default way of handling errors. Sometimes an error is in your logic and other times it is something in the environment. However they happen, the system will automatically log the error and stop the workflow process so the error can be reviewed. The end user will receive a red error prompt giving them basic information – but not usually any real details. As a reporting and admin user, you will need to review the error in the Error Log Report to see what error was logged and track down the offending action that way.
Customized Error Handling
The default error handling is usually the best approach – let the system log the error and stop. However, there are times when you may want to system to continue after an error. For example, you might not want to stop the entire process if an email cannot send. In this case you may want to customize the error handling.
You can customize the error handling on an action-by-action basis. All actions have a “Stop on Error” setting in their Options tab which is ON by default. If you turn that setting off, the system will skip that action if it throws an error and continue the workflow processing. It also provides you with a way to capture the error and save it into a Record field.
The settings are as follows:
- Turn OFF the “Stop on Error” setting.
- Enter the name of a field to log the error into such as “LastError” or “EmailError.”
- Customize the error text to write into that field or leave the error value blank to have the actual error logged into the field. Normally you would leave this blank so you can log the actual error.
The benefit of logging your own error is that you can check for the presence of an error in other workflow actions. Maybe you would want to route that Record to a special user if there was an error. In the case of the email failure, maybe you would want to route the Record to a customer service agent to validate the email address and/or manually send the failed notification.
Final Thoughts
As stated above, you probably would use the default most of the time. However, this technique can be useful for certain cases where you don’t want workflow to stop for specific problems. One thing to keep in mind is that, when you use this technique, the error is NOT logged to the normal Error Logs report. You would need to handle the error reporting yourself using the “Error to Field” setting.