Defensive Workflow Design Part 1 - Workflow History Lists

  • 13 October 2014
  • 2 replies
  • 562 views

Userlevel 7
Badge +10

Planning ahead

 

In addition to creating one to one mappings of Nintex and SharePoint content databases (Covered here: https://community.nintex.com/docs/DOC-1092). Workflow history lists can be created on a one to one basis for each workflow in the environment using the below steps:

 

  1. Navigate to Site Settings Nintex Workflow Manage workflow history lists. Click New from the ribbon and name the new History List something meaningful like the workflow name and history list. Example: ‘My Approval Workflow History List’
  2. Open the Nintex Workflow Designer and click Workflow Settings. Select the new history list from Workflow Options and click save.
    When you publish/re-publish your workflow all new instances of that workflow will use the newly provisioned workflow history list.

 

Performance

 

Typically we start to see performance degradation when a Workflow History list reaches 2,000 – 4,000~ list items. Even if performance is not noticeably impacted by Workflow History list size, better performance can be achieved by keeping this list size minimal.


When a list has grown too large two approaches can be taken to address the situation:

 

  • Purge the history list data. This can either be done manually or by utilizing our NWAdmin tool with the PurgeHistoryListData operation. More documentation in the attachment below.

 

  • A new history list can be provisioned and the workflows utilizing the history list can be republished using the newly provisioned history list. Note: Existing workflow instances will complete using the old history list.
    To locate existing workflow history lists in a SharePoint farm, this PowerShell script can be utilized:  How to quickly identify large lists in SharePoint

 

Design Considerations

 

  • Not all workflows may require a separate history list. If a workflow is seldom ran, or if it does not contain actions that log heavily to the history list, they can likely be left to use a shared history list.
  • If a workflow contains any loop logic (loop/for-each/state machines) consider leaving out actions such as ‘Log to History List’ as they can quickly fill a workflow history list if left unchecked.
  • Utilize the History list during the development and testing stages of your workflow and remove or disable them prior to production release.

 

More Information

 

Demystifying Workflow History (Part 1)

How to purge items from a large history list safely via PowerShell

How to quickly identify large lists in SharePoint

Defensive Workflow Design Part 2 - SharePoint Topology

Defensive Workflow Design Part 3 - Separation of Concerns

Defensive Workflow Design Part 4 - Slow Down and Speed Up

Defensive Workflow Design Part 5 - Batching


2 replies

This is Great!

Badge +1

A third option for SharePoint Server users, as it relates to Workflow History List maintenanance would be to add a Retention Policy to the List that culls the items through the implicit records management policy features (that are scheduled Friday/Saturday on most OOB systems).   This avoids using the NWAdmin tool or having to manually republish.   Caution, the best time to employ this is at the start of the solution not when the list has grown beyond tens of thousands.  However, a good one-two punch in that case might be to publish with a new list while simultaneously setting the retention policy on it.

Reply