What is it?
If you want to track content versions created between Workflow Activities in a Workflow Process, you can enable auditing of a Workflow Process. When you enable Workflow auditing, “snapshots” are taken of an item as it progresses through a Workflow Process.
By default, when you save an item that is in Workflow, the version number increases by “0.1” each time it is saved, and the version number increases to the next whole number when an item in Workflow completes a Workflow Process. You can view changes to the item as it was before and after the Workflow Process started and ended by major versions.
A snapshot is a record of the content of an item as it was at a specific moment in the Workflow Process. To be precise, a snapshot is taken when each Activity in a Workflow Process is finished. Taking snapshots allows you to compare the content of an item as it progressed through Workflow and view the changes that were made during each step (Activity). Snapshots are taken of all items that can go through a Workflow Process.
Where is it?:
It’s a setting associated with the Workflow Process Definition in the Workflow Diagram as shown below:
Why might this help:
In the event, we need to understand what minor version changes were made and who approved them within a previous workflow process. In particular, because we allow minor version content to publish to LIVE. This is still a minor version and an example of the following scenario
If editor B finishes a workflow process then the component progresses to version 2.0 and all minor version changes are otherwise lost. (I’ve included an example scenario below).
Why might this help – Example
– v1.0 enters workflow
– editor A updates to v1.1 workflow is progressed to Live Review
– the content is published live
– editor A assigns the workflow to editor B back to Staging activities
– editor B corrects a mistake in the content
– editor B progresses the item back to Live Review
Without the audit snapshots, it would not be possible to
1) confirm what the changes are between the version that editor A managed and editor B is managing – thus with further analysis determine which editor made the change that was subsequently published to LIVE.
2) confirm who made a specific change if it wasn’t the validator (given the separation of duties etc.) if the workflow instance went through more than one iteration of the process
How do I see this:
In the image below you will see
1 – the workflow process history
2 – the history of activities that had been finished as part of that process
3 – the activity after the first modification of the component
4 – the activity that a second modification was made it
5 – the specific work item we’re looking into
6 – as we have auditing on, we get the compare option
Limits / Risks:
1. Out of the box we still don’t get access to open the specific historical versions – only compare
2. BE AWARE THAT THIS BLOATS THE WORKFLOW TABLE WITH HISTORICAL INFORMATION!
The actual storage sizes have not been quantified; although this would be highly dependent on the quantity and velocity of items passing through workflow.
Mitigation: it has been agreed that only 30 days of history will be required to be kept within the CMS
3. Consumes resources (adds time) to make snapshots of every item in a bundle at the end of each activity
4. A copy of the component is saved off at each step of workflow even if the version didn’t change on that step. For our workflow, 7 copies of every component in the bundle were created every time it was run through workflow.
5. Publishing slows as it has more versions in the table to sort through. (Especially when the “publish in workflow versions if possible” checkbox is checked in the publishing dialog window.
In practice, we have found that the workflow auditing bloats up the production database too much and decreases performance so much that the value it provides does not overcome the performance loss. Currently after nearly 1 year with audit turned on and multiple issues root causes being traced back to auditing, we have disabled the feature.