Change Control and Document Locking
You can use document locking to achieve change control at a document level. This control is limited to areas controlled by document locking, such as the document’s structure and specific fields. Here is an example to illustrate an implementation of change control that uses document locking.
For the purposes of this example, assume the following facts about this implementation:
• The document workflow includes a state called “Restricted”.
• The document item has an “Assigned User” field that is never editable.
• An item type called a “Change Order” exists and is used to both request and authorize changes to a document.
• The Change Order workflow includes states called “Submit”, “In Development” and “Complete”.
• The Change Order item has an “Assigned User” field that is editable. This field must have a value when the document is in the state “In Development”.
• Items of type Change Order can be related to the document.
• The following aspects of document locking have been configured:
◦ Locking is required to edit documents of this type when the state is Restricted.
◦ Only users in the Assigned User field can lock the document.
• There are two rule-based pre-event triggers:
◦ The first only runs when a Change Order enters the In Development state and that Change Order is related to a document.
◦ The second only runs when a Change Order enters the Completed state and that Change Order is related to a document.
Here is what happens when a user, Dale, wants to make changes to a document under change control:
1. The document is currently in the Restricted state. This means that it must be locked before users can make changes to the document’s structure or any field controlled by locking.
2. Dale wants to make changes that require locking the document. So, Dale creates a Change Order and relates it to the document.
3. After the Change Order is approved for work, it is assigned to Dale for implementation by setting the Assigned User field on the Change Order.
4. Dale reviews the Change Order and moves its state to In Development.
5. The first event trigger runs and does the following:
a. It checks that the document is not locked and that the document’s Assigned User field is not filled in. If either of these are not true, the trigger aborts and does not allow the transition of the Change Order to In Development at this time. Another user is currently working on the document.
b. If the document is not locked and its Assigned User field is empty, the trigger performs two actions:
▪ It copies the value of the Change Order’s Assigned User field (Dale) to the document’s Assigned User field.
▪ It automatically locks the document for the Assigned User (Dale).
6. The document is now locked for Dale who can make the necessary changes to the document to fulfill the Change Order.
7. Once all changes have been made, Dale moves the Change Order to the Completed state.
8. The second event trigger runs. It unlocks the document and clears the document’s Assigned User field.
Dale’s changes are complete. Subsequent modifications to the same document by Dale or another user require another Change Order.