One of my favourite aspects of Collabware CLM (and how it stands out from the competition) is its rich audit trail that allows you to pull out most any tidbit of information that your heart desires. Want to see how many people viewed a given document? Collabware’s there for you. Need a list of all undeclared records or unclassified documents? No problem. Want to see what projects Bob was looking at before he left to go work at your competitor? easy, Collabware has you covered.
But of course, reporting will only be as good as the integrity of the underlying data and reporting isn’t the only issue. In order for our audit trail to be used as evidence during litigation, it needs to be trusted, complete and reliable. This blog post will highlight some of the best practices to ensure that your Collabware audit trail is mean, clean and full of insight to glean.
Get Collabware up and running, as soon as possible
Once you made the decision to go with Collabware, don’t hesitate to get it up and running, even if you feel like you’re not ready yet. The minute Collabware is up and running it starts collecting valuable data for every single document and list item (creation, modification, views, deletes and much more). The earlier you get Collabware collecting data the better off you’ll be, even if you’re still months away from completing your file plan. For example, you’ll be able to pull the average time that end users spend working on documents in each library allowing us to contextually set thoughtful and deliberate auto-declaration rules that don’t step on the toes of your end users.
Avoid turning off Collabware CLM
Ok, this may seem obvious to most, but we have seen instances where our client’s SharePoint Administrator has turned off Collabware in their production environment in order to test performance when adding in another third party product. Which meant, of course, that Collabware CLM was not able to capture audit activities or produced their globally unique ID’s (never mind classifying content against the file plan). This wouldn’t be a problem in non-production environments but certainly caused a headache since this was done in production. Some of our clients have gone as far as to have us set up alerts when Collabware is turned off to ensure the highest degree of integrity for their audit trail.
Don’t restore duplicated Site Collections into the same environment
Another client’s SharePoint Administrator wanted to test out some scenarios with Collabware’s new workflow capabilities; so, they made a copy of a site collection in production instead of playing with the copy in their test environment. The result was that many documents shared the same Unique ID (which was… um.. er.. no longer unique). This caused some erroneous audit trail entries for documents that now shared ID’s and while the problems stopped once the duplicated site collection was deleted and we were able to clean up the database but this could have caused concern from end users if they saw any unexpected audit entries.
Undo instead of redo
Another problem that we’ve come across is when performing scripted changes to SharePoint like migrating content from network file storage. Sometimes you may decide that after the script finishes you’re unhappy with the results. Typically, the easiest path is to restore a backup of the site collection content database and start over, but we’ll end up with ghost entries in the audit trail (i.e. entries in the Collabware reporting database for documents that don’t exist in the SharePoint contentdatabase). We’ll have to remember to also restore the Collabware audit trail databases (and organize some system downtime\content freeze and stopping of Collabware timer jobs) or write a script to undo what our original script to create a full story (i.e. have a delete for every item that we added but that we didn’t want to keep).
Careful when using migration tools
Not all migration tools are created equal as some are unable to persist the unique ID created by Collabware. As a result, you may need to augment your migration tools with scripts to ensure that ID's follow the content around when they are moved from one location to another with a third party migration tool as the unique ID is the critical bit of information.
Don’t delete your data, it’s valuable!
Again, this may seem obvious at first, but some clients need to delete their audit trail after documents are destroyed by Collabware in order to meet their needs around compliance (or avoiding FOI requests).
We suggest (and will review in a future blog post), how we can sanitize the audit trail (removing identifying information) but keeping some of it for future reporting and analytics.
Don’t throw your database server in the ocean
Ok, ok, I know, I know… this is silly, but it highlights the fact that a lot of these issues are outside of the control of Collabware and even SharePoint itself and likely applicable to any ECM platform.
You may want to consider creating some policies and procedures as part of your all-up governance plan around this topic to ensure that you create a shared understanding with the IT department on how to maintain the integrity of your audit rail and ensure that it provides the most value to your organization over the long run.