In this post, I’ll explain the steps to surfacing key ‘Workflow History’ details onto a SharePoint list item. Rather than having to navigate down into the Nintex Workflow History page to see who has reviewed, approved, rejected, or completed an item, you can access those details on the Nintex Form for the SharePoint item.
This solution ensures 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 to automate processes using SharePoint and Nintex is keeping an adequate Approval History for auditing and tracking purposes without overloading your Nintex database or SharePoint list where the details are stored.
As you may know, SharePoint Workflow History is essentially lost 60 days after a workflow is completed or canceled.
Nintex Workflow History works a little differently. There is no default job to automatically clean up Nintex Workflow History for completed and canceled workflows.
This is great because it allows you to retain access to the historical details of every workflow that has ever run within your organization. But, 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 both the Nintex database and the SharePoint list where the Nintex Workflow History is stored under control, and helps to avoid unnecessary performance issues.
So, with this in mind, we at Abel Solutions have started implementing an Approval History as part of the approval workflows we build for our clients. 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 is created in the following steps:
1. Add a new column on the list
Add a new ‘Multiple lines of text’ column to your list to store Approval History.
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).
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 you to create a single Approval History branch that you can run after every task action to reduce duplicate actions and keep your workflow size within reason.
4. Begin formatting for Approval History
On the new Approval History branch, start by checking to see if there is already a value in the Approval History column on the item.
If the Approval History column already has a value, start with that value and append the current approval details to the end.
5. Loop through all Tasks and Format Approval History
Now you’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 you have all of the task response details, you can combine them with the previous column value (if applicable) from Step 4.
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.
7. Continue routing
Next, 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.
8. Add Approval History column to Nintex Form
Lastly, add the new Approval History list column to your Nintex 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 this will give 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.
Interested in trying Nintex for SharePoint? Try it free for 30 days!