One of the fundamental components of SharePoint’s Content Management feature is Version History. If a list or library on your site tracks versions, you can view version history for items or files. The version history contains information about when the item or file was changed, who changed it, and information about what was changed. In libraries, the version history might also contain comments written by the people who made changes. It’s a valuable component for auditing the changes in List/Library metadata.

Recently a Colleague of mine asked me if it was possible to create a report on Version data as one of his Customers was interested in analyzing the different versions. I was reminded of a deployment I did for Microsoft a few years back where they had a very strict Change Control process and they also needed to analyze version data. It was a valid requirement when managing Projects in SharePoint so here’s how we did it.

1.  Enable Version History

First of all, turn on Versioning for your app. In this example, I am using the Project Issues app in the Free Project Management Template for SharePoint 2013.

2.  Create Log

The next step is to create an app to log the different versions. Since I started with a Project Issues list I simply created a second Issues App and called is the Project Issues Log. It has identical columns to the original Project Issues app so there is no need to build it manually.

3.  Build the Workflow

Using SharePoint Designer 2013 I created a very simple Workflow that writes to the Issues Log any time an item is created or modified in the Project Issues App. The Start Options in the Workflow are set according to these criteria. The Workflow has just one step to create a new item in the Issues Log and copy over the values from the original Issue.

4.  Test the Workflow

As with all Software, you need to verify that the data being written to the Log is correct so simply create and edit a Project Issue and then compare the Version History of the Issue to the data being written to the Issue Log. They should match exactly.

5.  Report on the Issue Log

Finally, once you have the data being written to the Log you can then report on it using views, grouping, and filtering. If you are using the full BrightWork product you can configure the reporting engine to rollup multiple Logs across multiple Programs and Projects. Enabling the SQL Datafeed feature in BrightWork would then allow you to feed this data to SQL for even more advanced analysis.