# Configuring Multi-Document Change Control (QualityDocs)

Multi-Document Change Control allows you to use the _Document Change Request_ (DCR) and _Document Change Control_ (DCC) objects to execute document release and obsolescence in a programmatic, controlled manner.

The individual components that support this feature are entirely configurable, allowing your organization to model many different business processes. This article provides some suggested configurations. New Vaults include a best practice configuration by default.


<div class="note-border alert-info">
  <div class="alert alert-info" role="alert">
    <div><i class="far fa-info-circle"></i></div>
    <div class="alert-text">
      <p><strong>Note</strong>: The <a href="/en/lr/42152/">Working with Multi-Document Change Control</a> article assumes that you’ve followed the recommended processes here. If your configuration is different, your organization’s users may require additional help.</p>
    </div>
  </div>
</div>



## Configuration Overview

To set up Multi-Document Change Control:

  * [Configure the object lifecycles][2] for _Document Change Control_, _Document Change Request_, and _Change Authorization_.
  * Associate applicable [shared document fields][3] to all document types that will use this functionality.
  * Add the _Change Authorization_ section to the _Document Change Control_ [object page layout](/en/lr/26387/).
  * Optionally, add the [special _Documents to be made Effective with Workflows_ and _Documents to be made Obsolete with Workflows_ sections][1] to the _Document Change Control_ object page layout.
  * [Enable change control][4] on any document lifecycles for document types that will use this functionality.
  * Optional: [Configure automated periodic review](/en/lr/72024/) options for your document lifecycles.
  * Select an appropriate _Document Change Control_ object lifecycle state for the _Implementation_ state type.
  * Optional (Veeva Training only): Configure [TRIA for Document Change Control](/en/lr/5722921/).

## Configuring Document Types & Lifecycles

Before beginning, determine which document types, subtypes, and classifications will use change control and which lifecycles are tied to those document types. Document types, subtypes and classifications which 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}
The Document Change Control feature includes both required and optional fields for mapping documents and their relevant details to *Document Change Control* records.

At minimum, we recommend associating the following shared document fields with the applicable document types:

* The **Planned Effective Date**, **Planned Obsolescence Date**, and **Obsolescence Approval** dates you selected while [configuring][15] the *Update Change Controlled Documents* entry action within **Admin > Settings > Application Settings**. If you're following the [recommended configuration][16], these fields are *Proposed Effective Date*, *Planned Obsolescence Date*, and *Obsolescence Approved*, respectively.
* The *Obsolete DCC* (`obsolete_change_control__v`), *Release DCC* (`release_change_control__v`), and *Change Authorization DCC* (`change_authorization_change_control__v`) fields are used to create a relationship between the document and a specific change control. By default, these fields include security overrides to hide them, as users do not need to interact with the fields directly. However, we recommend updating the override's default security to read only for full transparency within the Document Change Control process.

You can additionally organize fields into various Document Information panel [sections](/en/lr/1535/) in **Admin > Configuration > Field Layouts**. The below sample configuration for a *Draft to Effective* lifecycle document includes a mixture of standard and custom fields. Many fields in these lists are not specific to change controls, but can be useful when they appear alongside change control fields.

Within a "Change Information" section:

* *Requires DCC?* (`requires_dcc__c`)
* *Implementation Period (Days)* (`implementation_period_days__c`)
* *Change Authorization DCC* (`change_authorization_change_control__v`)
* *Obsolete DCC* (`obsolete_change_control__v`)
* *Release DCC* (`release_change_control__v`)

Within a "Status Dates" section:

* *Approved Date* (`approved_date__c`)
* *Proposed Effective Date* (`proposed_effective_date__c`)
* *Effective Date* (`effective_date__v`)
* *Superseded Date* (`superseded_date__c`)
* *Proposed Obsolescence Date* (`proposed_obsolescence_date__c`)
* *Obsolescence Approved* (`obsolescence_approved__c`)
* *Obsolete Date* (`obsolete_date__c`)
* *Withdrawn Date* (`withdrawn_date__c`)

### Document Lifecycles {#lifecycle-enable}

For any document lifecycles that should use change control, navigate to **Admin** > **Configuration** > **Document Lifecycles** and click into 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 the document is currently being routed 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][6] 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 do this by removing 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 Workflows

If you want Vault to automatically change the state of the associated _Document Change Control_ to the state indicated as its _Implementation_ state type [at the appropriate time][8], you should include the _Update Document Change Control State_ system action step in all applicable workflows on documents.

### Document Lifecycle State Entry Actions {#doc-entry-actions}

For Multi-Document Change Control, you can set up special entry actions on document [lifecycle states][7]. These document lifecycle state entry actions can streamline your process for complicated changes, but you can choose to configure Multi-Document Change Control without these.

#### Entry Action: CC: Set Change Control to Ready for 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 documents with the same lifecycle. For this lifecycle, the _Pending Change Control Approval_ state type is linked 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.

<div class="note-border alert-info">
  <div class="alert alert-info" role="alert">
    <div><i class="far fa-info-circle"></i></div>
    <div class="alert-text">
      <p><strong>Note</strong>: <strong>Known issue</strong>: Vault may display a server error if an action, such as rejecting a <em>Document Change Control</em> approval task, triggers both the <strong>CC: Update Change Controlled Documents</strong> object state entry action and the <strong>CC: Set Change Control to Ready for Approval</strong> document state entry action at the same time.</p>
    </div>
  </div>
</div>



#### Entry Action: Check and Close Multi-Document Change Control

When a document in a _Document Change Control_ enters the configured state, this entry action:

  * Checks the states of the documents associated with a _Document Change Control_, and verifies whether the _Document Change Control_ should be closed.
  * Automatically changes the _Document Change Control_'s state to its _Complete_ state type once all of the _Documents to be Released_ are in their _Steady_ state, and all of the _Documents to be made Obsolete_ are in their _Obsolete_ state.

To use this entry action, configure the document lifecycle to include this entry action for lifecycle states in both the _Steady_ and _Obsolete_ state types. The _Document Change Control_ object lifecycle must have a state assigned to the _Complete_ state type.

The automatic state change occurs just after the entry action is triggered. If the state change fails, details about the failure appear in the _Closure System Details_ field on the _Document Change Control_ record.

This entry action can take up to 30 seconds to complete for _Document Change Controls_ with many _Documents to be Released_.

## About the Default Change Control Objects {#objects}

Enabling Multi-Document Change Control creates two standard objects:

  * [**Document Change Control**][10]: Change Managers will link a _Document Change Control_ record to one or more documents in order 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.
  * [**Document Change Request**][9]: Users can create _Document Change Request_ records to track changes they'd like to see 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. Requests are linked to change controls through the _Governing Change Control_ field.

You can modify both of these objects by adding new fields to track additional details. We also recommend setting up object lifecycles.

## Configuring the Document Change Request Object {#dcr-object}

QualityDocs Vaults include the _Document Change Request_ object to generally support Vault users [requesting changes](/en/lr/825586/) for individual documents. 

In addition to this object's baseline [configuration](/en/lr/8255861/), we recommend the following optional DCC-specific configurations to best support your organization's DCC process:

* Add the _Exclude from DCC Auto-Linking_ field to the _Document Change Request_ object page layout. Alternatively, you can configure this field to be populated via [workflow record update steps](/en/lr/33550/#update-field-action) or [other automated data updates](/en/lr/25772/).
* [Configure the _Document Change Control_ object lifecycle][10] to include the **CC: Update Related Change Request** entry action.  This configuration allows the Change Control to automatically mark its related _Change Request_ records as _Approved_.

## Configuring the Document Change Control Object {#dcc-object}

We recommend that you do the following, but none of these steps are required:
1. Configure the _Document Change Control_ object lifecycle to include the **CC: Update Related Change Request** entry action on the _Approved_ state.
  * This allows the _Document Change Control_ record to trigger a state change on related _Document Change Request_ object records to their _Completed_ state.
  * We strongly encourage you to leverage this entry action. Without it, Vault does not automatically update change requests.
2. <a id="dcc-config-update-change-controlled-documents"></a>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 optionally sets certain fields on the documents.
  * When configuring this entry action, you'll choose the target document state type, and whether Vault should copy fields to documents. See [About the Update Change Controlled Documents Entry Action][16].
3. Configure the _Document Change Control_ object lifecycle to include the **Link Available Document Change Requests** entry action or user action on an appropriate state.
  * To make the action available for configuration within the lifecycle, assign it to the _Document Change Control_ object. During configuration, you can alternatively select the _Available in All Lifecycle States_ configuration option. This automatically adds a user action to all lifecycle states, then the actions are controlled within the lifecycle's **Atomic Security: Actions** settings. We recommend reviewing and updating atomic security settings according to your organization's requirements when you opt to use this setting.
  * When executed, this action updates the _Document Change Control_ to include active _Document Change Request_ records which target the same documents as the _Document Change Control_ as well as any DCC-related _Change Authorization_ records.
  * Vault locates DCC-related documents via their _Release DCC_ (`release_change_control__v`), _Obsolete Change Control_ (`obsolete_change_control__v`), and _Change Authorization DCC_ (`change_authorization_change_control__v`) document field values.
  * If the _Document Change Request_ has the _Exclude from DCC Auto-Linking_ checkbox selected, Vault does not add that _Document Change Request_ when executing this action.
4. Configure the _Document Change Control_ object lifecycle to indicate a state as the _Implementation_ state type.
  * If you have configured the _Update Document Change Control State_ system action step into your document workflows, Vault automatically changes the _Document Change Control_ record to this state once all the documents in the _Documents to be made Effective_ section are in the _Approved_ state and all the documents in the _Documents to be made Obsolete_ sections have the _Obsolescence Approved_ field set to _Yes_.
5. 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** setting is ON for these states. Making the _Document Change Control_ record inactive when it is complete 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.
  * Alternatively, you can configure independent approval workflows for the documents. If you use the [enhanced _Documents to be Made Effective/Obsolete with Workflows_ sections][1], users can initiate these document workflows directly from the _Document Change Control_ record.
6. Define workflows for the _Document Change Control_ object that moves records from _Ready for Approval_ to _Approved_ and _Closed/Completed_ or to _Closed/Cancelled_.
  * To ensure that workflow participants are able to see all documents they approve, include [workflow steps][11] before each task assignment step in the workflow.
7. Update the access control settings for the _Document Change Control_ object to ensure that the right users (Change Managers/Change Approvers) can create and manage change controls.
  * Change Managers/Change Approvers also require _View Document_ permission on any documents linked to a _Document Change Control_ record.
8. Create a custom tab so that users can view and work with change controls outside of the Admin area.

### About the Update Change Controlled Documents Entry Action {#about-the-update-change-controlled-documents-entry-action}

When [configuring][15] the **CC: Update Change Controlled Documents** entry action, Vault requires you to choose:

1. Which document state type to target with the **Document State Type** drop-down. When the entry action runs, the documents to be released are transitioned to 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.
2. Whether you want to **Copy Fields to Documents**. Typically, this option is only checked on the _Approved_ state. When the entry action runs, this option sets certain field values on the documents. The document fields are configured in **Admin** > **Settings** > **Application Settings**:
  * **Planned Effective Date**: When the entry action runs, Vault copies the DCC record's _Proposed Implementation Date_ field value to the selected field on the documents to be released. We recommend using the _Proposed Effective Date_: This field is based on the DCC's _Proposed Implementation Date_, which prevents users from selecting a date in the past by default. This field is included in the delivered application as a shared date field that you'll need to add to any document types that use change control.
  * **Planned Obsolescence Date**: When the entry action runs, Vault copies the DCC record's _Proposed Implementation Date_ field value to the selected field on the documents to be obsolesced. We recommend using the _Proposed Obsolescence Date_: This field is based on the DCC's _Proposed Implementation Date_, which prevents users from selecting a date in the past by default. This field is included in the delivered application as a shared date field that you'll need to add to any document types that use change control.
  * **Obsolescence Approval**: When the entry action runs, Vault sets the value of the selected field to _Yes_ on the documents to be obsolesced. We recommend using _Obsolescence Approved_. This field is included in the delivered application as a shared yes/no field that you'll need to add to any document types that use change control.

<div class="note-border alert-info">
  <div class="alert alert-info" role="alert">
    <div><i class="far fa-info-circle"></i></div>
    <div class="alert-text">
      <p><strong>Note</strong>: <strong>Known issue</strong>: Vault may display a server error if an action, such as rejecting a <em>Document Change Control</em> approval task, triggers both the <strong>CC: Update Change Controlled Documents</strong> object state entry action and the <strong>CC: Set Change Control to Ready for Approval</strong> document state entry action at the same time.</p>
    </div>
  </div>
</div>



## Configuring the Document Status & Workflow Initiation Sections {#doc-status-wf}

The following special sections, available to configure on the _Document Change Control_ object page layout, allow users reviewing the _Document Change Control_ to view the status of included documents and to start workflows on them directly from the _Document Change Control_ record details page:

  * _Documents to be Made Effective with Workflows_: Displays documents with the current _Document Change Control_ identified in the document's _Release Change Control_ field.
  * _Documents to be Made Obsolete with Workflows_: Displays documents with the current _Document Change Control_ identified in the document's _Obsolete Change Control_ field.

Users can select documents with the checkboxes on the left side of the section, then start workflows that are valid for the selected documents by clicking **Start Workflow**. This functionality does not support [legacy workflows](/en/lr/5205/).

These sections are useful if you use an approach in which users start document workflows on individual documents in the _Document Change Control_, driving the _Document Change Control_ to move forward once all documents are in an appropriate state. One advantage is that you can now easily send sets of documents to different groups of workflow participants.

While the legacy _Documents to be Made Effective_ and _Documents to be Made Obsolete_ sections cannot be removed from the _Document Change Control_ layout by [the standard method](/en/lr/26387/), you can create a simple [layout rule](/en/lr/51632/) to hide them. Configure the layout rule expression to always return _TRUE_, and to hide these sections:

  * _Documents to be made Effective_
  * _Documents to be made Obsolete_

## Configuring Document Change Control Object Workflows {#workflow-steps}

There are two common ways to configure object workflows to ensure that workflow participants are able to see all documents they approve:

  * Add a [_Cascade Document Roles_][12] 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**][13] 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 Workflow 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**. After the Workflow task is completed, we recommend repeating the **Check participant access to related documents** step before continuing the workflow.

## Configuring the Change Authorization Object Lifecycle

To allow users to provide verdicts on documents in the _Change Authorization_ section of the control, add _Change State To_ user actions to the _Created_ lifecycle state for both the _Approved_ and _Rejected_ states.

The _Change Authorization_ section on the DCC does not support [inline editing](/en/lr/31019/) for _Change Authorization_ record fields. Thus, in order to mark a _Change Authorization_ as _Needs Revision_ or _Make Obsolete_, you must click into the record, then edit the _Revise or Obsolete_ field. To streamline this process, we recommend configuring object workflows for _Change Authorizations_ that allow you to set the _Revise or Obsolete_ field, and to expose them as user actions on the _Created_ state of the _Change Authorization_ object lifecycle.

## Cascading eSignatures to Change Controlled Documents {#cascading-esignatures}

When using Multi-Document Change Control, your organization 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 (if configured) in the documents' generated signature pages. To do this, include one 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](/en/lr/46676/#configuring-to-make-esignatures-obsolete) from the change control to the documents. If necessary for your process, use the following option:

  * **Include Purpose in Cascade Verdicts**: Select this checkbox and fill in both the _Purpose for Release_ and _Purpose for Obsolescence_ fields. Configured purpose values will be cascaded along with eSignatures to documents and 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, your organization can configure _Document Change Control_ object workflows so that certain document lifecycle role assignments "cascade" down to the governed documents. This includes any documents included 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. If you use the default workflows, this step is automatically included.

### Roles

Vault automatically adds the following two 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][14])

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

_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, your organization 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 lifecycle states applicable 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 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](/en/lr/33550/#check-access) for information on setting up this workflow option.

## Scheduled Jobs

In some business processes, you must configure a scheduled job that moves documents into to 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:

<table class="wbord">
  <tr>
    <td>
      <strong>Job Description</strong>
    </td>
    <td>
      <strong>Document Conditions</strong>
    </td>
    <td>
      <strong>State Change To</strong>
    </td>
  </tr>
  <tr>
    <td>
      Post Change Control Sorting:<br> Locate all documents associated with an approved Document Change Control record. If they require training, move them to the issued state.
    </td>
    <td>
      <p><em>Approval Date</em> is today or earlier</p>
      <p>
        Requires training
      </p>
      <p>
        In lifecycle's <em>Change Control Approved</em> state
      </p>
    </td>
    <td>
      <em>Issued for Training</em> or equivalent state
    </td>
  </tr>
  <tr>
    <td>
      Auto-Effective Release:<br> Locate all documents which are in an approved but not-yet-effective state, and make those documents effective on the planned date.
    </td>
    <td>
      <p>Proposed Effective Date is today or earlier</p>
      <p>
        Requires training
      </p>
      <p>
        In Issued for Training or equivalent state
      </p>
    </td>
    <td>
      Document lifecycle's Steady state
    </td>
  </tr>
  <tr>
    <td>
      Auto-Effective Release:<br> Locate all documents which are in an approved but not-yet-effective state, and make it effective on its proposed effective date
    </td>
    <td>
      <p>Proposed Effective Date is today or earlier</p>
      <p>
        Training not required
      </p>
      <p>
        In lifecycle's Change Control Approved state
      </p>
    </td>
    <td>
      Document lifecycle's Steady state
    </td>
  </tr>
  <tr>
    <td>
      Auto-Obsolescence:<br> Locate all documents which are in an effective state, but have been approved for obsolescence. Automatically set them to an obsolete state on the planned date.
    </td>
    <td>
      <p>Proposed Obsolescence Date is today or earlier</p>
      <p>
        Obsolescence Approved is Yes
      </p>
      <p>
        In lifecycle's Steady state
      </p>
    </td>
    <td>
      Document lifecycle's Obsolete state
    </td>
  </tr>
</table>

<div class="note-border alert-info">
  <div class="alert alert-info" role="alert">
    <div><i class="far fa-info-circle"></i></div>
    <div class="alert-text">
      <p><strong>Note</strong>: You can use Multi-Document Change Control without scheduled jobs if all documents released by a change control go directly into their lifecycle’s <em>Steady State</em>.</p>
    </div>
  </div>
</div>



<div class="note-border alert-info">
  <div class="alert alert-info" role="alert">
    <div><i class="far fa-info-circle"></i></div>
    <div class="alert-text">
      <p><strong>Note</strong>: Note: Running the following jobs at the same time may cause conflicts: 1) An Auto-Effective Release job and an Auto-Obsolescence job, or 2) An Auto-Effective Release job and a Post Change Control Sorting job. To avoid such issues, ensure your configuration runs these jobs at different times.</p>
    </div>
  </div>
</div>



## How to Hide Single-Document Change Control

If your organization wishes to use Multi-Document Change Control but is currently using Single-Document Change Control (SDCC), we recommend these actions to hide the SDCC options:

  * Inactivate the _Document Change Control_ document type.
  * Clear the **Use Document Change Control** checkbox within document type details for all document types.
  * Set the _Document Change Control Lifecycle_ status to _Inactive_.

## Related Permissions {#related-permissions}

Users must be assigned a permission set with the below permissions in order to work with DCCs and DCRs.

Additionally, these users require the appropriate document role permissions, including:
* Edit Fields allows users to associate a _Document Change Request_ with a document, and Change Managers must have this permission on all documents related to their change controls.
* View Content allows users to see a document's Viewable Rendition. Any user reviewing and approving changes must have this permission on all documents included in the change control. You can ensure correct permissions by including the [_Cascade Document Roles_][12] system action step in change control workflows.

| Permission Label | Permission | Controls |
|---|---|---|
| Objects: Document Change Control | Read, Create, Edit | Allows Change Managers to create and update change controls |
| Objects: Document Change Request | Read, Create, Edit | Allows users to create change requests on documents if they have access to those documents<br>Allows Change Managers to include or exclude change requests in change controls |


 [1]: #doc-status-wf
 [2]: #objects
 [3]: #doc-fields
 [4]: #lifecycle-enable
 [5]: #field-settings
 [6]: #doc-entry-actions
 [7]: #doc-states
 [8]: #implementation
 [9]: #dcr-object
 [10]: #dcc-object
 [11]: #workflow-steps
 [12]: #cascade_role
 [13]: #check-participant-access
 [14]: #custom_relationships
 [15]: #dcc-config-update-change-controlled-documents
 [16]: #about-the-update-change-controlled-documents-entry-action