# Configuring Multi-Document Change Control (Document Control) QualityOne Vaults allow you to use the _Document Change Request_ and _Document Change Control_ objects to execute document release and obsolescence in a programmatic, controlled manner. The individual components that support the Multi-Document Change Control feature are entirely configurable, allowing your organization to model many different business processes. This article provides some suggested configurations. Vaults created after the 16.0.0 release will include a best practice configuration by default.
## Configuration Overview {#overview} Configuring your Vault to use Multi-Document Change Control involves the following steps: 1. [Configure the object lifecycles for _Document Change Control_ and _Document Change Request_][1] 2. [Apply the shared document fields to all applicable document types][2] 3. [Enable change control on any document lifecycles for applicable document types][3] 4. [Configure user permissions][11]
## Configuring Document Types & Lifecycles {#doc-type-lifecycle} Before beginning, determine which document types, subtypes, and classifications will use change control and which lifecycles correspond to those document types. Document types, subtypes, and classifications that require change control may share a lifecycle with documents that do not. Within the document lifecycles, you must identify specific lifecycle states that serve as "document review complete" and "document has an approved change control." These may be existing states in the lifecycle, or you may need to create new lifecycle states. ### How to Configure Document Fields {#doc-fields} Making a document type, subtype, or classification ready for change control requires that you add various fields to it: 1. Navigate to **Admin > Configuration > Document Fields**. 2. Add the shared document fields from _Multi-Document Change Control_ settings to the document type, subtype, or classification. If you're following the recommended setup, use the _Proposed Effective Date_, _Proposed Obsolescence Date_, and _Obsolescence Approved_ fields. 3. Add the _Obsolete Change Control_ and _Release Change Control_ shared document fields to the document type, subtype, or classification. Vault uses these fields to create a relationship between the document and a specific change control. By default, these fields have security overrides to hide them because users do not need to interact with the fields directly through the Doc Info page. You can remove or change these security overrides if needed. ### Document Lifecycles {#lifecycle-enable} For any document lifecycles that should use change control, navigate to **Admin > Configuration > Document Lifecycles** and click on the lifecycle. Click **Edit** and select the **Document Change Control** checkbox. Click **Save**. This setting enables Multi-Document Change Control for the document lifecycle. ### Document Lifecycle States {#doc-states} When you enable Document Change Control on a document lifecycle, you must select specific lifecycle state for these state types: * **Pending Change Control Approval State**: This state should indicate that the document is ready to be routed with a change control for approval. * **In Change Control Approval State**: This state should indicate that Vault is currently routing the document for approval with a change control. * **Change Control Approved State**: This state should indicate that the document has an approved change control and is ready for release. Vault includes [entry action functionality][5] based on these state types to inform the related _Document Change Control_ record that a document is ready for approval, in approval, or approved. When setting up the document lifecycle, make sure that neither of the states specified for these state types allows users to route a document for approval or release directly. You can remove workflow or state change-type user actions from the lifecycle state. Users should only be able to progress documents out of the _Pending Change Control Approval State_ or into the _Change Control Approved State_ through the related _Document Change Control_ record. ### Document Lifecycle State Entry Action {#doc-entry-actions} For Multi-Document Change Control, you can set up a special entry action on document [lifecycle states][4]. This entry action can streamline your process for complicated changes, but you can configure Multi-Document Change Control without it. #### Entry Action: CC: Set Change Control to Ready for Approval {#action-cc-approval} Add this entry action to the lifecycle state specified for the state type _Pending Change Control Approval_. This entry action attempts to perform a state change on the related _Document Change Control_ record. However, this state change only succeeds if all of the change control's related documents are in the appropriate state. For example, a change control includes two (2) documents with the same lifecycle. For this lifecycle, Vault links the _Pending Change Control Approval_ state type to the _Reviewed_ state. When the Document Author moves the first document into _Reviewed_, Vault tries to move the change control to _Ready for Approval_ but finds that the second document is still in the _In Review_ state. The next day, the second document enters the _Reviewed_ state and Vault again tries to move the change control. This time, the state change succeeds because all documents are in the correct state. ## Configuring the Default Objects {#objects} Enabling Multi-Document Change Control creates two (2) standard objects: * **Document Change Request**: Users can create _Document Change Request_ records to request and track changes on a document. A change request is only linked to a single document, but a single document may have many change requests. The _Document Change Request_ object includes a document reference field: _Target Document_. Change Managers can choose to include specific change requests in a change control. Vault links requests to change controls through the _Governing Change Control_ field. * **Document Change Control**: Change Managers can link a _Document Change Control_ record to one (1) or more documents to control the change process. You may also configure this object to link to the _Document Change Request_ object, which lets users provide further detail for complex changes. You can modify both objects by adding new fields to track additional details. We also recommend setting up object lifecycles. ### Document Change Request Object {#doc-change-req-obj} We recommend that you do the following. Many of the following steps are optional. * Optional: Configure the _Create Related Record_ user action on specific document lifecycle states that allow document viewers to create a _Document Change Request_ record without navigating away from the relevant document. We recommend including this in at least the _Steady_ state of the relevant document lifecycles. * Update the access control settings for the _Document Change Request_ object to ensure the right users can create requests. Users will also need the _View Document_ permission on a document to create a related change request. * Create a custom tab so that users can quickly view and work with requests. * Optional: Configure user actions for the _Document Change Request_ object lifecycle. Your configuration should include actions that move the request to _Closed_ or _Rejected_ status. * Optional: Configure notifications for the _Document Change Request_ object lifecycle. You should set these up as _Send a notification_ entry actions for the _Accepted_, _Closed_, and _Rejected_ lifecycle states. If you chose to use Matching Sharing Rules for access control on object records, you may use the object roles (such as _Owner_) as notification recipients. This allows you to notify the user who created the request. * Optional: [Configure the _Document Change Control_ object lifecycle][6] to include the _CC: Update Related Change Request_ entry action. This configuration triggers Vault to automatically mark _Change Request_ records as _Approved_ when the related _Change Control_ moves into an _Approved_ state. ### Document Change Control Object {#dcc-object} We recommend that you do the following: * Configure the _Document Change Control_ object lifecycle to include the _CC: Update Related Change Request_ entry action on the _Approved_ state. This configuration triggers Vault to automatically mark _Document Change Request_ records as _Completed_ when their related _Document Change Control_ record moves into an _Approved_ state. Without this entry action, Vault doesn't update change requests automatically. We strongly recommend leveraging this entry action. * Configure the _Document Change Control_ object lifecycle to include the _CC: Update Change Controlled Documents_ entry action on the _Ready for Approval_, _In Approval_, and _Approved_ states. This entry action changes states of related documents to synchronize state changes between the _Document Change Control_ and the documents to be released, and can also populate certain fields on the documents. When configuring this entry action, you choose: * Which document state type to target with the _Document State Type_ drop-down. When the entry action runs, the documents to be released enter this state type. We recommend using the _Pending Change Control Approval_ document lifecycle state for the _Ready for Approval_ state, the _In Change Control Approval_ document lifecycle state type for the _In Approval_ state, and the _Change Control Approved_ document lifecycle state type for the _Approved_ state.  * Whether you want to _Copy Fields to Documents_. Typically, this option is only enabled on the _Approved_ state. When enabled, the action populates certain fields on the documents. If you select this option, you can configure which shared document fields Vault populates in **Admin > Settings > Application Settings** in the _QualityDocs_ section. You must add the selected field to any document types that use change control. The following fields are available: * **Planned Effective Date**: When the entry action runs, Vault copies the value of the _Proposed Implementation Date_ field on the _Document Change Control_ to the selected document field on the documents to be released. We recommend selecting _Proposed Effective Date_. * **Planned Obsolescence Date**: When the entry action runs, Vault copies the value of the _Proposed Implementation Date_ field on the _Document Change Control_ to the selected document field on the documents to be obsolesced. We recommend using _Proposed Obsolescence Date_. * **Obsolescence Approval**: When the entry action runs, Vault updates the value of the selected field to _Yes_ on the documents to be obsolesced. We recommend using _Obsolescence Approved_. * Configure the terminal lifecycle states (_Closed/Completed_ and _Closed/Cancelled_) in the _Document Change Control_ object lifecycle. Verify that the **Records in this state become inactive** checkbox is selected for these states. This ensures that the document is released from any restrictions associated with change control, and makes the document eligible to be part of a future change control. * Update the access control settings for the _Document Change Control_ object to ensure that the right users (Change Managers and Change Approvers) can create and manage change controls. Change Managers and Change Approvers will also need _View Document_ permission on any documents linked to a _Document Change Control_ record. * Create a custom tab so users can quickly view and work with change controls. ### Configuring Document Change Control Object Workflows {#workflow-steps} Define workflows for the _Document Change Control_ object to move records from _Ready for Approval_ to _Approved_ and _Closed/Completed_, or to _Approved_ and _Closed/Cancelled_. There are two (2) common ways to configure object workflows to ensure that workflow participants can see all documents they approve: * Add a **[Cascade Document Roles][8]** step before any task. This step grants the task participants necessary document permissions, allowing your organization to manually resolve access issues. * Add a **[Check participant access to related documents][9]** step and a subsequent decision step using the _Participant Access Check Results_ workflow variable to track which users lack membership to appropriate roles on which documents. Include _Notification_ and _Task_ steps to the appropriate user or group to resolve any role membership issues if the _Participant Access Check Results_ workflow variable **is not blank**. We recommend repeating the _Check participant access to related documents_ step after the task before continuing the workflow. ## Cascading eSignatures to Change Controlled Documents {#cascading-esignatures} When using Multi-Document Change Control, you can configure _Document Change Control_ object workflows so that eSignatures "cascade" down to the change controlled documents. The cascaded signatures appear in the document audit trails and in the documents' generated signature pages, if configured. To do this, include one (1) or more tasks with eSignatures in the object workflow. Then, add a **System Action: Cascade eSignatures** workflow step to the object workflow. Within this step, you should select each verdict that should cascade and select the **Manifest eSignature on documents** checkbox for each. Selecting the **Cascade only current eSignatures** checkbox in the Cascade Verdicts section ensures that Vault only cascades current, non-obsolete signatures from the change control to the documents. You can use the **Include Purpose in Cascade Verdicts** option by selecting its checkbox and fill in both the _Purpose for Release_ and _Purpose for Obsolescence_ fields. Configured purpose values will cascade along with eSignatures to documents and are captured in documents' audit trails. To manifest purposes in your eSignature pages, you need to add a token (`dcc_signature_purpose__v`) to your eSignature template. ## Cascading Document Roles {#cascade_role} When using Multi-Document Change Control, you can configure _Document Change Control_ object workflows so that certain document lifecycle role assignments "cascade" down to the governed documents. This includes any documents in _Documents to be Released_, _Documents to be Made Obsolete_, and any documents with a custom relationship to the _Document Change Control_ record. Cascading document roles prevents a situation where a workflow participant has permission to access only some of the governed documents but approves the change control, causing impacts to unreviewed documents. We recommend including a _System Action: Cascade Document Role_ step before each task assignment in a workflow for _Document Change Control_ records. This step is part of the default workflows. ### Roles {#roles} Vault automatically adds the following two (2) document lifecycle roles to all document lifecycles. The _Cascade Document Role_ step can only assign users to these roles. * _Document Change Control Approver_ * _Document Change Control Reviewer_ * _Viewer_ ([details for custom relationships][10]) By default, the _Document Change Control Approver_ and _Document Change Control Reviewer_ roles grant the _View Document_ and _View Content_ permissions for all lifecycle states. You can edit the permissions as needed, but removing these permissions prevents the feature from working as intended. By default, Vault does not include any override rules for these roles. ### How to Set Up Cascade Role Steps {#setup-cascade} _Cascade Document Roles_ is a type of system action in the _Document Change Control_ object workflow configuration. To configure it: 1. Add a **System Action** step to the workflow. This step should occur before any task assignments in the workflow. 2. Select **Cascade Document Roles** in the **System Action** drop-down. 3. Select the **Access Role** to assign workflow participants on all related documents. 4. From the **Grant Document Access To** drop-down, select the workflow participant group to assign to the selected document lifecycle role. You can choose multiple participant groups if needed. ### Custom Relationships {#custom_relationships} If your Vault uses custom relationships (other than _Documents to be Released_ and _Documents to be Made Obsolete_) between documents and _Document Change Control_ records, Vault assigns users to the _Viewer_ document lifecycle role, rather than the roles described above. This occurs for every workflow participant group mapped to either _Document Change Control Approver_ or _Document Change Control Reviewer_ via the _Cascade Document Roles_ step. ## Checking Participant Access to Related Documents {#check-participant-access} When using Multi-Document Change Control, you can configure _Document Change Control_ object workflows to verify that all users in a workflow participant group are members of desired Application Roles on every document related to a _Document Change Control_ record. These roles should have at least _View Content_ permissions on all applicable lifecycle states while documents are linked to the _Document Change Control_. This includes any documents with a _Documents to be Released_ or _Documents to be Made Obsolete_, or any custom relationship to the _Document Change Control_ record to which workflow participants may need access. If any user lacks access to one (1) or more documents, Vault populates the workflow variable with the value **is not blank**. If the workflow variable **is blank**, all users have necessary access to all related documents. In some cases, **is blank** could also mean that the workflow configuration is incorrect. See Configuring Object Workflows for more details on setting up this workflow option. ## Scheduled Jobs {#jobs} For some business processes, you must configure a scheduled job that moves documents into the next lifecycle state based on what happened with the change control. Because this state varies by lifecycle, you must create this set of jobs for each document lifecycle that uses change control. Most organizations will need the following jobs:
Job Description Document Conditions Change State To
Post Change Control Sorting:

Locate all documents associated with an approved Document Change Control record. If they require training, move them to the issued state.		 Approval Date is today or earlier

Requires training

In lifecycle's Change Control Approved state		 Issued for Training or equivalent state
Auto-Effective Release:

Locate all documents in an approved but not-yet-effective state, and make those documents effective on the planned date.		 Proposed Effective Date is today or earlier

Requires training

In Issued for Training or equivalent state		 Document lifecycle's Steady state
Auto-Effective Release:

Locate all documents in an approved but not-yet-effective state, and make it effective on its proposed effective date		 Proposed Effective Date is today or earlier

Training not required

In lifecycle's Change Control Approved state		 Document lifecycle's Steady state
Auto-Obsolescence:

Locate all documents in an effective state, but have been approved for obsolescence. Automatically set them to an obsolete state on the planned date.		 Proposed Obsolescence Date is today or earlier

Obsolescence Approved is Yes

In lifecycle's Steady state		 Document lifecycle's Obsolete state
## Hiding Single-Document Change Control {#hide-single-doc} If your organization wants to transition to Multi-Document Change Control but is currently using Single-Document Change Control (SDCC) , we recommend these actions to hide the SDCC options: * Set the _Document Change Control_ document type status to **Inactive**. * Clear the **Use Document Change Control** checkbox within document type details for all document types. * Set the _Document Change Control Lifecycle_ status to **Inactive**. ## Configuring User Permissions {#user-permissions} Vault provides two (2) security profiles that include the required permissions through permission sets: * _Document User with Change Management_ is appropriate for Change Managers * _Document User with Change Request_ is intended for any full user allowed to submit change requests. ## Related Permissions {#permissions} You can complete all the steps in this article with the standard _System Administrator_ or _Vault Owner_ security profile. If your Vault uses custom security profiles, your profile must grant the following permissions and document role permissions :
Type Permission Controls
Security Profile Objects: Document Change Control: Read, Create, Edit Ability to view, create, and modify Document Change Control records.
Security Profile Objects: Document Change Request: Read, Create, Edit Ability to view, create, and modify Document Change Request records.

Allows users to include or exclude change requests in change controls.
Document Role Document Lifecycles: States: Security Settings: Edit Fields Allows users to associate a change request with a document.

Change Managers must have this permission on all documents related to their change controls.
Document Role Document Lifecycles: States: Security Settings: View Content Allows users to see the Viewable Rendition for a document; users responsible for reviewing and approving changes should have View Content permission on every document included in the change control. Admins can ensure correct permissions by including the System Action: Cascade Document Roles step in change control workflows.
[1]: #objects [2]: #doc-fields [3]: #lifecycle-enable [4]: #doc-states [5]: #doc-entry-actions [6]: #dcc-object [7]: #workflow-steps [8]: #cascade_role [9]: #check-participant-access [10]: #custom_relationships [11]: #user-permissions