This post walks you through the steps I use to surface key Workflow History details onto a SharePoint list item. So, rather than having to navigate down into the Nintex Workflow History page to see who has Reviewed/Approved/Rejected/Completed an item and any associated comments, all of those details are more readily available on the Nintex form for the SharePoint item itself. This is also a good solution to make sure that these details are not lost with the workflow history when recommended database cleanup actions are performed—automatic, scheduled, or otherwise.
One of the most common challenges we experience when working with clients to automate processes using SharePoint and Nintex is keeping an adequate Approval History for audit and tracking purposes, without overloading the Nintex database or SharePoint list where Nintex Workflow details are stored.
As you may know, SharePoint Workflow History is essentially lost 60 days after a workflow is Completed or Canceled (here’s a great article that explains this in more detail if you’re interested).
Nintex Workflow History works a little differently; there is no default job to automatically clean up Nintex Workflow History for Completed and Canceled workflows. While this may seem like a good thing because it allows you to retain access to the historical details of every workflow run ever, if left unchecked this can lead to performance issues. Our standard recommendation is to implement a script that runs on the server and performs the same type of cleanup actions for the Nintex Workflow History as the automatic SharePoint cleanup. This keeps the Nintex database and the SharePoint list where the Nintex Workflow History is stored under control and helps to avoid unnecessary performance issues. There is a great two-part blog post on Nintex Connect which discusses this in detail – check out Part One here: Demystifying Workflow History (Part 1).
So, with this in mind, we’ve started implementing an Approval History as part of the approval workflows we build for our clients. Basically, after every task action is completed, we capture all of the pertinent details that we might want to reference later, and store those details to a column on the list. We can add this list column to our list item form and set it to read only via Nintex Form rules.
The solution essentially boils down to the following steps:
Step 1 – Add a new column on the list
Add a new Multiple lines of text column to your list to store “Approval History”.
Step 2 – Update task actions to capture Task IDs
Update your approval workflow to capture the Task ID for each task action that you are assigning (see “Store task IDs in” field in screenshot below).
Step 3 – Add a State machine
If you don’t already have a State machine as a part of your workflow, add one. This will allow us to create a single Approval History branch that we can run after every task action to reduce duplicate actions requiring maintenance and keep our workflow size within reason.
Step 4 – Begin formatting for Approval History
On the new Approval History branch, we start by checking to see if there is already a value in the Approval History column on the item.
If it’s not the first time through (i.e. the Approval History column already has a value), then we will start with that value and append the current approval details to the end.
Step 5 – Loop through all Tasks and Format Approval History
Now we’re ready to loop through all Task IDs captured in Step 2 to query the Workflow Tasks list for all tasks that were just completed and retrieve the following fields (stored into workflow variables):
- Assigned To (Display Name) – this is easiest with the Set variable action
- Modified date
Once we have all of the task response details, we can concatenate them together with the previous column value (if applicable) from Step 4.
Step 6 – Populate Approval History column
Update the Approval History list column with the new task details (mltApprovalHistory variable).
Best practice tip: Since we are looping and could have multiple entries to add to the Approval History column, make sure to include a Commit pending changes action after the Update item action – this will help reduce the risk of batching errors.
Step 7 – Continue routing
The last step in the workflow is to route the workflow to the next approver or task assignment. You can use a Switch action to evaluate against a value that is updated each time a task is assigned.
Step 8 – Add Approval History column to Nintex Form
Add the new Approval History list column to your form. The list item form in the screenshot below was created with the Nintex Responsive Forms Designer, with rules applied to hide the Approval History for New Mode and disable the control for Edit Mode.
I’m sure there are many different variations for how you may use this solution, but hopefully this gives you a good starting point for enhancing your users’ experience when interacting with your Nintex/SharePoint–automated business processes. Also, please note, the examples shown in this post show Nintex for SharePoint 2016; however, this solution is also relevant for previous versions of Nintex for SharePoint as well as Nintex for Office 365.