Auditing Field-Level Changes Using Muhimbi SharePoint Audit 2.0

Our SharePoint Audit product is no longer available. Instead, please check out this alternative product from our sister company: Aquaforest CheckPoint.

As part of the series about New features in Muhimbi SharePoint Audit 2.0 I would like to dive into a great new addition, which is the auditing of field level changes, a feature unique to our product.

As you may be aware, SharePoint’s native auditing capabilities are somewhat limited. You may, with a lot of effort, be able to track that an item has been changed ( by Item ID, sigh), but there is no way to find out which field has been changed and what the old or new values are.

Sure, you can enable ‘Version History’ on a list, but that only provides a little bit of detail, must be enabled manually on every list and the details cannot be queried as part of an Audit Report.

As tracking field level changes is rather useful, we have decided to add it to the core product and treat it the same as any other audit even type, resulting in the following advantages:

1. Auditing of this kind of information is automatically enabled when a Site Collection or list is created. There is no need to manually enable it.

2. Field changes are automatically included when the audit logs are queried or reports are generated, including all filtering and pivoting options.

So, if you are familiar with the product then it all works like any other audit event type. You specify either at the Farm, Web Application or Site Collection level that you want to track the Field Change’ event type and the system sorts it all out for you.

Once enabled, all field level changes are audited automatically. See the following screenshot for an example that shows a single audit entry for a change to the standard Task List.

When generating a full Audit Report all changes are grouped together as follows (Click to enlarge)

That’s it. Nice, powerful, integrated, intuitive. Download your free trial version here, no registration needed,

.