One requirement we are seeing more often for regulated clients is the requirement to update certain properties after a document has been formally approved with electronic signature. Typically, clients consider the document and properties to be one approved entity and would require a property change to go through a complete version and approval cycle. Our clients often need the ability to update a subset of these properties. For example, a document is approved and set to become Effective in 2 weeks, but delivery from a supplier is delayed, so the implementation of the SOP must be delayed another week. Re-versioning or re-approval should not be required to make this update to the Effective Date property. This post will discuss options on how to properly build a compliant system that allows for post-approval property updates.
Background
In regards to post approval property updates, most clients agree that some of these properties – not all – should have the ability to be modified in a controlled manner. Users shouldn’t be able to modify compliant-related properties (Approval Date, Document Number). But certain users should be able to update other properties. Example may include Implementation/Effective Date, Training Period, Author/Subject Matter Expert, Reference Documents, etc. These properties should be capable of being updated without versioning the document, but must be done in a controlled manner.
Reasons why updates to these properties are required post approval include:
- Document is Approved and set to become Effective 30 days from today. Schedules change and implementation needs to be pushed out another X weeks.
- Reference Documents – A new reference document could be released post approval. The existing document has no updates, except the addition of the referenced document which now needs to be added to the Referenced Documents property.
- Author fields are sometimes used when Periodic Review Notifications are initiated. Users often change roles and positions. The system should allow author information to be updated so Periodic Review notifications are sent to the correct people
In each of these cases, the content is not being updated nor are important compliance-related properties. The document shouldn’t need to be versioned and routed for approval just for these property updates that do not impact the content of the document or the compliance-related data.
Options for Post Approval Property Updates
We have seen several approaches companies use to control post-approval property updates.
In all 3 scenarios, assume that the approved document has approximately 10 properties on it. The Document Control group has determined that it should have the ability to update 2 of those properties post approval.
Option 1: Control via SOPs
Typically companies will limit the ability to edit properties post approval to a specific group of users (i.e. Document Control). The properties that these users have the authority to update are specified in a SOP (i.e. Implementation Period and Author). When Document Control goes to edit the properties of a document post approval, all 10 properties are displayed and editable, but Document Control knows they are only allowed to update Implementation Period and Author property per the SOP that they are trained on. Document Control will update the properties, keeping the document version the same. The system will audit that a specific user went in and updated the properties, but the audit trail would not specify which properties were updated. This process works fine if you have a small number of users making these updates and you can trust them to not make any mistakes.
It should be noted that this solution may be more readily accepted by customers using Alfresco versus Documentum as Alfresco allows a configurable audit trail to record all before and after property values. The audit trail will contain all before and after property values and not just the attributes that were modified.
Option 2: Limit Properties Displayed
Some companies want greater control over which properties are updated post approval. Companies will modify the properties screen so a user can only choose to update certain properties post-approval (i.e. Implementation Period and Author). The other 8 properties are not editable and can optionally be displayed in read-only mode. Any updates to the properties post approval will be audited as a property update as detailed in option 1. To implement this option, most applications will require a customization.
Option 3: Limit Properties Displayed with Custom Audit Trail
The final approach is to limit the properties displayed as editable while having a custom audit trail to record to and from values along with a reason for change. As discussed in Option 2, recording the to and from values is easier in Alfresco than Documentum. Documentum requires custom audit trail code for the to and from property values. However, to capture the Reason for Change requires a customization to the Audit Trail for both applications. This option is by far the most complex.
Summary
The need to have more flexibility to manage properties post approval is becoming more of a standard request from both regulated and non-regulated clients. There are multiple out of the box and custom approaches that are available with both Documentum and Alfresco that allow this functionality to be implemented in compliant manner. The solution right for you is really dependent upon your culture, user base, and technical direction.
Andrey B. Panfilov says
Auditing of both previous and new attribute values was introduced in Documentum 6.0