“Log in the History List” is extremely helpful in debugging and evaluating your workflow. But it can cause a fair bit of trouble, particularly on-premises, if it’s not used properly.
I thought it’d be helpful to summarize why you’d use “Log in the History List” and what to do to keep your environment in shape. Unless specifically mentioned, features and recommendations apply to both Nintex for SharePoint and Nintex for Office 365.
Why Use “Log in the History List”
The action is one of the most common and easiest ways to log workflow status, or simply to track a variables value.
A few actions are able to capture error occurrence and messages. These can be stored in workflow variables and then added to the workflow history. You will find error handling in Office 365 works a bit differently. “Call HTTP Web Service,” for example, will deliver the error messages from the web service call in the response content.
Logging information after action execution:
This is not a separate action, but it’s good to know when working with Nintex for SharePoint that workflow actions have a “Common” button in their configuration screens. One of the options is “Message to log on completion”. It allows you to log information to the history list right after the workflow has executed the action.
What to Watch Out For
Here are the best practices when using “Log in the History List” and working with the history list in general:
Development vs Production:
When deploying a workflow from development to production, remove all unnecessary actions (aka actions you used for debugging) from “Log in the History List.” Not only will your history list thank you, but your workflow will be lean and streamlined.
Remove the action from any loop you have in production workflows. If you don’t, and you loop through a part of the workflow 100 times, the action will execute 100 times and add 100 entries to the workflow history list.
SharePoint List Limitations:
“Log in the History List” creates entries in a SharePoint list. You can find a summary of all lists on each site by going to Site Settings > Nintex Workflow > Manage workflow history lists. The screen will show you all workflow history lists for your particular site, as well as the item count. Given that we are working within SharePoint boundaries, it is recommended to keep this list below 10,000 items (5,000 if you are using the default list view threshold). The limit is put in place as a SQL throttling limit. What happens when you get beyond the configured threshold? Well, in instances where you exceed the threshold, it is more efficient to lock the entire table in question. This table locking can prevent other users and workflows from accessing and manipulating that data.
NOTE: this threshold cannot be changed in SharePoint Online!
Keeping Your Environment in Shape
So, what can we do to keep our environment lean and fit? First and foremost, keep in mind the design principles listed above. Also, consider the following:
Multiple history lists:
Create separate history lists for each workflow. Each workflow can be associated with one history list only, so keep the SharePoint list limitations in mind. Don’t associate every workflow with the same history list; it will quickly reach the SharePoint list threshold and cause performance issues.
One of the first things to check when running into performance issues is the associated workflow history list item count. If it exceeds the recommended threshold, use the maintenance screen to trim it.
Instead of logging errors in the associated workflow history list, implement logic after actions like “Call Web Service” that can determine if an error has occurred and handle it appropriately. This could be a notification email to the administrator. An even more advanced technique would be to include logic that lets the workflow rectify the issue.
SharePoint Timer Job:
In both SharePoint and SharePoint Online, a timer job called “Workflow Auto Cleanup” will remove the association between the workflow and the history list. This is done for performance reasons. Once a workflow is completed, by default the connection between the workflow and the workflow history is deleted after 60 days. The time span of 60 days can be adjusted in SharePoint (though not in SharePoint Online) but this can — read “will” — have major implications on your farm’s performance. Handle this with care! Additional information on the timer job can be found here.
NOTE: this does not impact the workflow history information in Nintex’ database. More information on the differences can be found in the Nintex Community here.
In summary, stick to the principles above at all costs when working in production environments. SharePoint and your users will thank you. Development environments are traditionally short-lived (from a content perspective) but you might still want to consider some of the principles to make designing and testing of your workflows a breeze.
Visit the Nintex Community today to learn more and engage in conversations with fellow Nintex users!