There are many ways to debug workflows while in development and also when live in production. This is an overview of the methods that can be used and tips on when and when not to use them.
Log in History List
The most used method to get quick information about the status of the workflow, or the output of a variable. Be careful not to overuse this action by placing it in loops or leaving debugging information in place while in production.
History is stored in the SharePoint Workflow History list and is truncated by SharePoint after a configurable amount of time. History is also stored in the Nintex Workflow database to allow users to review history much longer after SharePoint removes its list data. This has a great feature, but make sure you are aware and possibly trim history information from databases after some time or databases will fill up too. See Chad Austin’s post on Demystifying Workflow History (Part 1) for details.
Remove debugging information when going live in production by disabling this action or deleting them.
Have a secondary workflow. One method that can be of assistance is to have a workflow as the primary production workflow that is used on a daily basis. Have an exact replica workflow, but with Log in History List action is key areas that does not start automatically. If you run into an issue, then run the secondary workflow to debug it on the same list item. This could help in finding what may have gone wrong.
Use a switch or condition. In your primary workflow you can have history data logged in reaction to metadata in a list item. For instance, on your custom form, if the user is an admin you can present them a checkbox on the form. When selected the workflow will use log to history throughout the workflow. If left unchecked, history data can be skipped by the condition working around the Log in History List.
Govern your environment. Make use of multiple web applications when developing. If you are not developing workflows in their own farm, make an attempt to have a separate web application so that the workflow runs in a unique App Pool in IIS different from the Production site. This will help production to not be slowed down by development workflows. Use multiple Nintex Databases. In the case of a complex, or many workflow site collection, create a Nintex Database just for this site collection. Use multiple history lists. The more you have, the less chance that one workflow will effect another because of history list usage. And if one workflow’s history is more important than another, having them separated allows easier management of the other.
Common Settings
In most actions there is a Common Settings tab. Within that tab you could find “Message to log on completion”. This value will log a message in the workflow history when the action has completed. Similar to Log in History List, but without a separate action. Very useful, but be aware of the same usage scenarios you could run into as Log in History List.
Error Handling
Some actions have built in Error Handling. This will allow the workflow to capture errors when they occur and allow the designer to react appropriately without causing the workflow to end.
For actions like Web Service calls or Execute SQL, you can follow-up these actions with a Set a Condition action to test if an error occurred. Then you can react in any way necessary. This could be ending the workflow but after a notification is sent out, or try again, but with an updated value.
