Recovering Workflow History after 60 days

​​​​Workflow history is one of two things to SharePoint users. I suspect for the majority, they aren't even aware of it, and don't have any need for it. For a small minority, they are fully aware of it for one important reason – compliance.

Workflows are nearly always used as part of a larger business process, and often these business processes require auditing to ensure compliance with whatever industry standard the business operates with.

When SharePoint workflows are used, workflow history is usually seized upon by users as being an easy way to audit compliance. After all, it's easy to get at isn't it?

Certainly while the workflow is in progress, and for a couple of months afterwards it is. But what happens when the end of year audit arrives, and the auditor goes to look at the history for a workflow completed 11 months ago? Disaster – it's not there! There must have been many a frantic phone call between panicking compliance officers and frustrated IT staff along the lines of this:

• [Compliance officer] "My workflow history has been deleted! The auditor is going to fail us! Where has it gone?"
• [IT support] (probably after Googling "Workflow history deleted") "This is by design. SharePoint deletes workflow history after 60 days"
• [Compliance officer] "WHAT?! Nobody told me that! Can you recover it?"
• [IT support] "We can, we'll just need turn off the timer job and then restore the entire SharePoint farm for each month in question."
• [Compliance officer] "How long will that take?"
• [IT support] "Hmmm…."

Both parties are at fault here. The compliance officer for writing a feature of SharePoint into the compliance process without knowing how it worked, and IT for not explaining the 60 day "deletion" actually happens. The good news is though, workflow history isn't deleted, all we need to do is make it easier to find.

So Where Is Workflow History after 60 days?

Put simply, it's in the same place as it's always been. There's a hidden list in every SharePoint site with the workflow feature activated called "workflow history" and it's under lists, so pointing your browser at http://[sitename]/[subweb]/lists/workflow%20history/ will show you this list. It's not pretty, and certainly not usable by an end user in its default view, but it is the same content that was available from the item that the original workflow ran on.

All that happens after a workflow has been closed for 60 days is that the relationship links between the item (list item or document) and the workflow history are removed from the database by a timer job. The reason this is done is that a workflow can consist of many individual steps, each of which gets recorded in the history list.

Maintaining those links in the database for every workflow that ever runs in a site slows performance down. So Microsoft implemented a clean-up job to remove the links, making it appear from the item that the workflow history is gone. It's possible to disable the timer job, but this has to be done at the application level, will kill performance in the long term, and doesn't help you get back the "missing" workflow history.

Making Workflow History Usable Again

Knowing that all Workflow History is available in a list, all we need to do is link it back to the original item using a calculated column and a view. The basic steps are:

• Create a view of the workflow history list that uses the filtered ID to present the history of a particular workflow in a recognisable format.
• Create a new calculated column in the list or library that is associated with the workflow.
• Write a formula in the calculated column that inserts the item/document ID into a link that can be passed to a view of the workflow history list.

Once we've completed these steps, any user who can open the item will be able to see the new link to the workflow history and view that. Now for the nitty gritty:

Create views of the Workflow History List

1. Open the workflow history list at http://appname/subweb/workflow%20history/
2. Create a new shared view; you'll need one for each list that has a workflow associated with it – if there's only one, call the new view "audit view", otherwise "workflow name – audit view" or something similar.
3. You'll need to identify the List or Library ID (GUID) – You can use the full history list for this.
4. As a minimum, add the following columns to the view:

   Date Occurred

   User ID

   Event Type

   Outcome

   Description

5. Sort the view by "Date Occurred"
6. Filter the view by "List ID" (List ID is equal to GUID – include the braces)
7. Group by "Primary Item ID", then by "Workflow History Parent Instance"
8. Save the view, try it out – add any other customisations your audit process may need.

At this point the view will return all history for a particular list, in the next steps we'll create a link that opens and filters workflow history for a particular item.

Create the calculated column for a list/library

1. Within the list that is associated with the workflow, add a new calculated column. Do this for each list from which you need to see the workflow history.
2. Enter the following formula, replacing appname and subweb with the address of your site, and viewname with the view you just created:
   =CONCATENATE("http://appname/subweb/Lists/Workflow%20History/viewname.aspx?&FilterField1=Item&FilterValue1=",ID)
   ​​​
3. Add this column to the default view, or create an "auditor's view" of the list, containing this column and any other pertinent information.
4. Now users can click on the link created dynamically by this column to return a filtered view of the workflow history, containing audit information on each step in every workflow that ran for this list item.

​

Make the workflow history easier to read

Out of the box, the workflow history contains a lot of GUIDs instead of real names (I suppose this is where deleting all those links made sense to Microsoft). To make it more human legible, you can add further calculated columns to the workflow history list to turn some of those column values back into real names. A good example is the workflow name, which is represented by "workflow association ID"

1. Add a new calculated column called "Workflow name" to the workflow history list.
2. Use the following formula:
   =IF([Workflow Association ID]="{GUID of particular workflow}", "Name of particular workflow",IF([Workflow Association ID]="{GUID of another particular workflow}", "Name of another particular workflow"))
   ​​
3. Now save and add this column to your workflow audit views.

That's all. It's clearly not as straightforward as being able to use the OOTB workflow history from the item, but if it means you can still access the same information anytime without harming the performance of the database, it's definitely worth doing! If you know you're going to need workflow history for multiple sites, it's probably worth adding the views at least to the site template before the sites are created, and you could even add the columns to the default libraries with some placeholder values to aid deployment.

About the author

Andy Walman

Head of Infrastructure

Andrew has been a part of the Fuse team since day one. He is responsible for successfully migrating your business from one based on servers to the cloud, ensuring that you have the products and solutions that you need to enhance your operations, along with a suitable and efficient system design. He will also talk you through the process step-by-step to ensure that you have all the information you need to understand how to maximise this new support​.