Audit Records for document version changes: Workflow vs Metadata

How you handle audit logging for version changes depends on your organizational needs. In this article, FileHold shows some different options for how to handle records for changes made to documents.

FileHold features automatic version control. When changes are needed, the original document is preserved, and the latest version is pushed forward as the primary document. Often, organizations need a note of what was changed between versions, a simple summary to assess the scope and scale of variations. FileHold lets you track these notes in workflow, metadata, or a combination of both. The right solution depends on the need to track this information as part of the audit log, or record of document interactions in FileHold. In some organizations, an informal record is sufficient; in others, a more controlled method of tracking information along with timestamps is essential for the audit record. Both approaches have benefits that should be considered.

Custom metadata is the simplest, way of recording explicit changes between versions. FileHold allows organizations to create as many or as few metadata fields they need in the schema to help organize, classify, or control information relating to the document or record. There are different formats for metadata that are advantageous to version tracking. The simplest metadata field is a text field, which allows the users to input information freely – a common field for this might be “Version Changes”, and the user can add notes. Another useful field is a FileHold-managed drop-down list, which allows for common reasons to be selected, like “Typographical error” or “Formatting issue”. Anytime a drop-down list can be used, it saves input time. Both could be used – a drop-down for common revision reasons and a text field for further details if needed. Because metadata is searchable, the version notes become another tool to use to locate particular versions of a document that might contain specific content known in the revision process.

Metadata can be forced with the schema as a “Required” field. If the metadata is not present, FileHold will prevent the document from being added until the required fields are completed. In version notes, this can be an annoyance because the primary version will not have any special values. This can be mitigated with using an “Initial Value” for the metadata field, such as “First Draft” or “Primary version”. This completes the metadata field, satisfying the “required” flag. When a new version is checked in, the schema can also “Clear value at check-in”: this way, the required field’s outdated information is cleared, and the newly blank field must be completed by the user prior to FileHold adding it to the Library. This ensures the user enters version notes each time.

Image

Metadata, although vital, may not tell the whole story for an audit record. For instance, there may have been several authors working on the new version, but no way to track whose comment was whose; there may be time stamps for when revisions were made that need to be tracked; there could be additional processes in other software which need to happen alongside the file being revised, that also need to be documented. Some of this information can be captured in the Document Usage Log. This is a fantastic tool for seeing the whole picture of document use, but it does not capture detail. Consider this log:

Image

The log shows the metadata was edited by Chris, but not which fields nor what content. Perhaps the version notes were edited, or maybe the Invoice number was changed. The Document Usage Log shows what FileHold function happened, who did it, and when, but gives no hint as to the detail of their actions.

It is possible to use the document's version history to see a record of changes. This tool is accessible to all users, and is very good for looking at specific version and seeing changes. The user first needs to select the version, and then select "Edits to Metadata" to see a record of what was changed. 

Image

Here, FileHold lets the user select the version and shows the metadata field highlighted in bold. In many cases, this is sufficient for seeing the detail of what was changed, but can become "unwieldy" to move between multiple versions. This is good for finding the information, but not as a reporting tool.

If these details are critical to the audit log, FileHold’s Workflow module is a more robust solution. Workflow, FileHold’s most popular optional feature, provides a customizable review and approval process for documents and records. These can be highly structured processes, or casual adaptable sequences to allow flexibility. A simple process can be created to allow users to run documents through review cycles. Workflow provides the users with not only structure to add comments and attach supporting documents as needed, but also create potential due-dates and audit logs of specific actions in an easy to review Workflow Status Report.

Image

FileHold’s Workflow can be adapted as needed. One typical use is where a review is needed by multiple people, but these are selected ad-hoc considering the project needs. FileHold’s Workflow template can allow the initiator to define the review participants in the same task to notify everyone their participation is required to complete the review. Each reviewers’ comments are logged, along with a timestamp, to show their participation as part of the audit record. Alternatively, there may be a formal review process where different departments need to submit a review one-by-one. This linear process can be done easily with Workflow, where the recipients could be users (such as a manager) or groups (such as a department) that can be locked into the process or made selectable by the initiator. Again, FileHold’s Workflow is a flexible solution to document and log user activity.

The key factor in deciding the best option between workflow or metadata is the detail needed in the audit record. With FileHold’s Document Usage Log, the event and action are recorded but associated details are minimal. With workflow, the actions are tasks, which are assignable and require specific steps to complete. The courses of action are up to the workflow to define, and FileHold will assign, track, and move to the next text once complete. The only downside to using workflow is that the log of actions done is in the workflow status report, which may be of limited visibility to the document, unlike metadata which is prominent.

If you need the precision of workflow and the visibility of metadata, both can be used at the same time to create a complete record of version notes. By using a metadata field for notes, you can have the workflow task instruct the user to include their version notes when they update. This gives you all the ease of seeing the version notes with the document metadata, while also generating a complete audit record with timestamps of actions.

This is just one of the many ways FileHold can help track, control, and organize documents and their versions. For more information, contact us at sales@filehold.com.