# Configuring Checklists

Checklists are a data entry method that allows a user to enter data in question and answer format. Vault allows you to build templates using the _Checklist Design_, _Section Design_, _Question Design_, _Available Answer Design_, and _Dependency Design_ objects. As part of the configuration, you can then set up lifecycle state user actions or entry actions, which will create an instance of the checklist template, called a checklist, that a user assigned to the _Checklist Respondent_ role can interact with to respond to questions. As part of the configuration, you can also configure the <a href="/en/gr/66930/">workflow</a> appropriate to your use case.

Checklists are available for all applications. You can enable Checklists in your vault using the _Enable Checklist_ option by navigating to **Admin > Settings > General Settings** and setting the **Enable Checklists** option in the _Checklist_ section.

For help designing your checklists, see <a href="/en/gr/52824/">Designing Checklists</a>.



<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>: <a href="/en/gr/49033/#canceling-deleting-checklists">Deleting</a> a <em>Checklist</em> does not delete its related <em>Available Answer</em> records. However, deleting a <em>Checklist Type</em> deletes its related <em>Available Answer</em>, <em>Response Order Answer</em>, and <em>Response Selected Answer</em> records if they are not associated with an existing <em>Checklist</em> record or related record.</p>
    </div>
  </div>
</div>



## How to Enable Checklists for an Object {#enabling}

_Checklist Designs_ are created for specific objects (the _Target Object_) from which they will be initiated. To begin creating a checklist design for an object, you must first create a _Checklist Type_ in **Admin > Configuration > Checklist Types** and associate it with the _Target Object._ After creating a _Checklist Type,_ Vault automatically creates a set of related [checklist objects][1] specific to the target object that are used to store checklist responses for the _Target Object_, as well as <a href="/en/gr/66930/">_Pending Acceptance_ and _Accepted_ workflows</a> for the _Target Object_. For example, if the _Target Object_ is _Audit_, the name of the related checklist objects includes the _Target Object_, such as _Audit Checklist_, _Audit Section_, and _Audit Response_.

If the _Target Object_ has two parent fields, Vault randomly selects one to reference in the _Checklists_ object.

  1. Navigate to **Admin > Configuration > Checklists Types**.
  2. Click **Create**.
  3. Enter a **Label** for your checklist type, for example **Audit Checklist Type**.
  4. Select a **Target Object**.
  5. Optional: Set up [matching fields][4] if you plan to create multiple [_Checklist Designs_][2] records for this _Checklist Type_.
  6. To enable <a href="/en/gr/52824/#versioning">**Version Control**</a> for the _Checklist Type_, select **Yes**.
  7. Optional: Use the [Checklist Types][9] page to configure optional and required fields to display on the Visual Checklist Designer.
  8. Click **Save**.  

## Default Configuration

Certain configuration components are automatically available upon enabling checklists in your Vault:

  * Various objects ([object list][7]) with fields and basic details
  * Lifecycles for each of the objects
  * <a href="/en/gr/66930/">_Accepted_ and _Pending Acceptance_ object workflows</a>

## Visual Checklist Designer Fields {#visual-checklist-designer-fields}



The Checklist Types page displays the optional and required fields for the <a href="/en/gr/537448/">Visual Checklist Designer</a>. Each field is categorized under its corresponding design object: _Section Design_, _Question Design_, and _Available Answer Design_. The optional fields provide you the ability to configure fields to display on the Visual Checklist Designer based on the type of checklist. For example, if the checklist contains only multiple choice questions, Admins building the checklist may not need to see fields such as _Decimal Places_, _Minimum Answer Value_, and _Maximum Answer Value_. But, they may need to see fields such as _Weight %_, _Score_, and _Question Help Text_.


<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>: For an optimal user experience, ensure the fields configured to display in the Visual Checklist Designer match the fields configured to display in the <a href="/en/gr/47738/#design_objects"><em>Design</em> object</a> <a href="/en/gr/26387/">page layout.</a></p>
    </div>
  </div>
</div>




### Workflows {#workflows}

See <a href="/en/gr/66930/">Configuring Checklist Workflows</a>.

## Configuration Overview {#overview}

You can build checklist designs directly through your Vault by creating records for the various objects, but Vault also provides a loader that simplifies the process. The loader allows you to create a full checklist design, including sections, questions, available answers, and question dependencies, by loading a single CSV file. Additionally, you can export your completed checklist designs and upload them to other Vaults or modify designs and upload them to the same Vault. See <a href="/en/gr/50438/">Checklist Design Loader</a> for more details.

To configure a checklist:

  * Optional: <a href="/en/gr/26387/">Configure object layouts</a> for _Checklist Design_ to show the related _Section Design_ records and for _Section Design_ to show related _Question Design_ and _Dependency Design_ records. Completing this step first provides you an easier way to create related object records because you can do so from the _Checklist Design_ and _Section Design_ record detail pages.
  * Optional: <a href="/en/gr/26387/">Configure object layouts</a> for _Checklist Design_ to show child _Checklist Design Translation_ and _Checklist Field Translation_ records.
  * <a href="/en/gr/1269/">Define picklist options</a> for the _Checklist Type_ picklist.
  * <a href="/en/gr/18769/">Create a _Checklist Design_ object record</a>. The _Checklist Design_ record represents the design for a specific checklist. When creating a _Checklist Design_, you can optionally set _Aggregate Checklists_ to _Yes_ if you want to instantiate a single runtime checklist that is created by <a href="/en/gr/52824/#aggregate">aggregating two or more approved checklist designs</a>. You can also create a _Checklist Design_ record by <a href="/en/gr/52824/#copying-checklist-design">copying an existing checklist design</a>. You can configure the _Deep Copy Checklist Design_ user action on the _Draft_ and _Approved_ _Checklist Design_ lifecycle states. If you have enabled version control for the _Checklist Type_, you may also be able to create a _Checklist Design_ record by creating a <a href="/en/gr/52824/#versioning">new version</a> of an existing checklist design.
  * Once you save a new _Checklist Design_ record or select an existing _Checklist Design_ from the <a href="/en/gr/44069/#object-record-list-page">object record list page</a>, Vault directs you to the <a href="/en/gr/537448/">Visual Checklist Designer</a>. You can use this tool as an alternative to the <a href="/en/gr/50438/">Checklist Design Loader</a> or the <a href="/en/gr/52824/">traditional checklist design</a> options. If the _Checklist Design_ is an aggregate checklist, Vault directs you to the _Checklist Design_ record detail page instead.
  * <a href="/en/gr/18769/">Create one or more _Section Design_ records</a>. These represent sections within the checklist. You can add introduction or question sections to a checklist design. Introduction sections provide instructions to users responding to checklists and cannot contain questions. Question sections can contain one or more questions. For _Checklist Designs_ with _Aggregate Checklists_ set to _Yes_, add <a href="/en/gr/52824/#aggregate">sub checklists</a> instead of question sections.
  * <a href="/en/gr/18769/">Create the series of _Question Design_ records</a>. Each record represents a single <a href="/en/gr/66932/">question</a>. For multiple choice questions, you must also create _Available Answer Design_ records after creating the question. For each question design record, you can optionally include <a href="/en/gr/66932/#guidance_text">question guidance text</a> and <a href="/en/gr/66932/#reference-docs">reference documents</a>.
  * <a href="/en/gr/18769/">Create _Dependency Design_ records</a> for any question dependencies that you need to configure. When the checklist design is complete, move it to the _Approved_ lifecycle state by selecting the **Approve for Use** user action.
  * <a href="/en/gr/30683/">Configure lifecycle state entry actions and/or lifecycle state user actions</a> to initiate a checklist response within the lifecycle configuration for the related object.
  * Optional: <a href="/en/gr/26387/">Configure the object page layout</a> for the target object to show related _Checklist_ records.
  * <a href="/en/gr/30683/">Configure lifecycle state entry actions</a> to complete a checklist response within the lifecycle configuration for the related object.
  * Optional: To enable ad hoc questions, add the _Ad Hoc Questions Allowed_ field to the _Checklist Design_ <a href="/en/gr/26387/#fields">layout</a>. Then, set **Ad Hoc Questions Allowed** to **Yes** on _Checklist Design_ records to allow respondents to add ad hoc questions to checklist instances. Note that users must have the _Create_ permission on the relevant _Response_ object type, accounting for any applicable <a href="/en/gr/33946/">Dynamic Access Control (DAC)</a> assignments, to add ad hoc questions to a checklist.
  * Optional: To enable ad hoc sections, add the _Ad Hoc Sections Allowed_ field to the _Checklist Design_ <a href="/en/gr/26387/#fields">layout</a>. Then, set **Ad Hoc Sections Allowed** to **Yes** on _Checklist Design_ records to allow respondents to add ad hoc sections to checklist instances. Users must have the _Create_ permission on the relevant _Response_ object type, accounting for any applicable <a href="/en/gr/33946/">Dynamic Access Control (DAC)</a> assignments, to add ad hoc sections to a checklist.
  * Optional: [Configure welcome notification messages][32] that Vault will send to respondents assigned to complete a checklist.
  * Optional: Configure optional fields to display on the <a href="/en/gr/537448/">Visual Checklist Designer</a>.


<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>: If you <a href="/en/gr/15057/#add-fields">add new object fields</a> of field type <em>Lookup</em> to <em>Checklist</em> objects or any checklist-related objects, ensure you select <strong>Do not copy this field in Copy Record</strong>.</p>
    </div>
  </div>
</div>



## Objects Supporting Checklists {#objects}

The Checklists feature relies on a set of objects that represent the design of a checklist, as well as a set of objects that support actual instances of each checklist design:

### Design Objects {#design_objects}

The following objects support the design, or template, for a checklist:

  * **Checklist Design Master**: For _Checklist Types_ with version control enabled, each record represents a master list of checklist design versions.
  * **Checklist Design**: Each record represents a single checklist design.
  * **Sub-checklist Design**: For _Checklist Designs_ with **Aggregate Checklists** set to **Yes**, each record represents a join to a sub checklist.
  * **Section Design**: Each record represents a section within a single checklist.
  * **Question Design**: Each record represents a single question within a single checklist
  * **Available Answer Design**: Each record represents a multiple choice option related to a single multiple choice question within a single checklist.
  * **Dependency Design**: Each record represents a dependency between a dependent question or section and a multiple choice answer on the controlling question.
  * **Question Design Reference Document**: Each record represents a document attached to a checklist question for the respondent to view.
  * **Checklist Design Translation**: Each record represents an imported checklist translation language and is a child of the _Checklist Design_.
  * **Checklist Field Translation**: Each record represents the translated text for each field in a translated checklist. These records are children of the _Checklist Design Translation_ object.
  * **Library Question**: Each record represents a question in the _Question Library_.
  * **Answer Library Design**: Each record represents a multiple choice option related to a single multiple choice _Library Question_.
  * **Library Question Reference Document**: Each record represents a document attached to a _Library Question_ for the respondent to view.

<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>: Changes to the design objects that occur after a checklist is initiated do not affect checklists that were already created. Design changes will only affect checklists created after saving and approving the design changes.</p>
    </div>
  </div>
</div>



### Checklist Objects {#checklist-objects}

The following objects support instantiated checklists, based on a _Checklist Design_, and their responses:

  * **Checklist**: Each record represents an instantiated checklist related to a specific target object record.
  * **Sections**: Each record represents a question section within the instantiated checklist.
  * **Responses**: Each record represents a single question and response provided within the instantiated checklist. _Response Date_ fields are only populated for <a href="/en/gr/66932/#question-design">_Date_ questions</a>. _Response Number_ fields are only populated for <a href="/en/gr/66932/#question-design">_Number_ questions</a>.
  * **Dependencies**: Each record represents a dependency between two _Response_ records in the instantiated checklist.
  * **Available Answers**: Each record represents options for a specific multiple choice question. Once a respondent has answered the question, the unused _Available Answer_ records become inactive.
  * **Response Reference Document**: Each record represents a reference document uploaded by an Admin to a question for a respondent to view.
  * **Response Document**: Each record represents a document uploaded by a respondent to a checklist question's _Related Documents_ section.
  * **Sub-Checklist**: Each record represents a sub-checklist of an instantiated aggregate checklist.
  * **Response Selected Answer**: Each record stores the respondents multiple-choice answer for each response. If an existing record already stores the selected answer (or answers for checkbox questions), Vault does not create a duplicate record and the _Response_ record will reference the appropriate existing record.
  * **Response Order Answer**: Each record stores the existing order of available answers on instantiated checklists. For example, if _Checklist Design A_ has one (1) multiple choice question with randomized answers A, B, and C, a _Response Order Answer_ record is created for the first instantiated checklist with the order A, B, C. If a second checklist is created with the same order, no record is created. If a third checklist is created with the order C, B, A, another record is created with the new answer order.

As of the 25R2 release, the following fields are no longer in use:

* _Translation Versions_ field on _{Target Object} Checklist_ is replaced by _Translation Reference_
* _Answer_ field on _{Target Object} Dependency_ is replaced by _Controlling Answer_
* The following fields on _{Target Object} Available Answer_:
  * _Response_: Not populated as _Available Answer_ records are shared across multiple checklists
  * _Selected_: _{Target Object} Response Selected Answer_ object stores selected answers from respondents.
  * _Order_: _{Target Object} Response Order Answer_ object stores the order of multiple-choice answer options.

## Setting up Questions and Answers {#setup}

See <a href="/en/gr/66932/">Checklist Question & Answer Setup</a>.

## Matching Fields {#matching}

In cases where you are configuring multiple checklist designs, Vault uses the matching field selections (_Checklist Design Matching Field_ and _Target Object Matching Field_) to determine which checklist design to use based on how the field value on the object record matches the value on the _Checklist Design_ record. You can choose to leave these settings blank if you aren't creating multiple checklist designs.

For example, if you wanted to create a checklist in a _Change Control_ record based on facility, you would need to create a new _Facility_ field on the _Checklist Design_ object that references the _Facility_ object. You would then select _Facility_ for both the _Checklist Design Matching Field_ and _Target Object Matching Field_. When a user creates a _Change Control_ record for the Pleasanton facility, Vault creates a checklist based on the checklist design that also has the Pleasanton facility selected.

If you configure matching fields, the field on the _Checklist Design_ record must reference the same data as the field on the target object:

  * The picklist fields on each object must use the same global picklist.
  * The object reference fields on each object must point to the same (third) object.

## Checklist Type (Picklist) {#checklist-type}

_Checklist Type_ is a picklist assigned to the _Checklist Design_ object. You must configure picklist options from **Business Admin > Picklists > Checklist Type**. When creating the user action or entry action to initiate checklists, you will choose a _Checklist Type_ to create, which maps to the value on the _Checklist Design_ record. When a user initiates a checklist, Vault will determine which design to use based on the _Checklist Type_ selected on the design and on the entry or user action.

If you want to instantiate a checklist using only matching fields, ensure you use the default value _Not Applicable_ as the _Checklist Type_ when creating the user action or entry action. Selecting _Not Applicable_ directs Vault to use only the matching fields defined in the _Checklist Type_. If you do not configure matching fields and have multiple checklist designs, ensure you select a _Checklist Type_ picklist value other than _Not Applicable_ to ensure the appropriate _Checklist Design_ record is instantiated.

## Checklist Entry Actions & User Actions

Certain entry and user actions are available for checklists:

  * [Start checklist][21]
  * [Complete checklist][22]
  * [Update Related Aggregate Checklist Designs][35]
  * [Sync Checklist Design Lifecycle States][23]
  * [Delete in Background][24]

### Entry & User Actions to Initiate Checklists {#initiate_checklists}

In order for users to initiate checklists, there must be a _Start checklist_ entry action or user action configured on the state of the object lifecycle where you want checklists created.

If you configure the **Start Checklist** action as a user action, ensure you configure the 'target object' <a href="/en/gr/66930/#accepted_workflow">_Accepted_ workflow</a>. If you configure the **Start Checklist** action as an entry action, ensure you configure the 'target object'  <a href="/en/gr/66930/#pending_acceptance">_Pending_ _Acceptance_ workflow</a>. You should configure the checklist using only the user action approach or only the entry action but not both. Respondents assigned to complete a checklist will not receive the [configured welcome notification message][32] if the Start Checklist action is configured as an entry action.

For _Checklist Types_ with _Version Controlled_ set to **Yes**, the **Start Checklist** action will instantiate the _Checklist Design_ record in the state that is associated with the _Completed_ <a href="/en/gr/30683/">state type</a>.

When creating a **Start Checklist** action, you must specify:

  * **Checklist Type**: By default, this is set to _Not Applicable_. Select a **Checklist Type** value other than _Not Applicable_ if you do not have matching fields configured.
  * **Use Aggregate Checklists**: By default, this is set to _No_. Select _Yes_ to <a href="/en/gr/52824/#aggregate">aggregate</a> content at runtime from the specified sub checklists in the specified order if the _Aggregated Checklist Design_ and sub checklists are in the lifecycle state associated with the _Completed_ state type.
  * **Assign as Available Respondents**: (Entry action only) Select a role from the target object record. When the entry action initiates the checklist, Vault will assign the users in the selected role to the _Checklist Respondent_ role on the checklist. Ensure _Matching Sharing Rules_ or _Custom Sharing Rules_ are enabled on the target object before selecting a role.

### User Action to Complete Checklists {#complete_checklist}

The _Complete checklist_ entry action is automatically added for the target object lifecycle for both new _Checklist Types_ and existing _Checklist Types_. Admins cannot remove this entry action in the completed state because _Complete checklist_ is a system entry action. The entry action clears all disabled responses, and calculates the _Checklist Score %_ and copies the value to the _Score_ (`score__sys`) field on the appropriate _\<target object\> Checklist_ (`<target object>_checklist__sys`) runtime object.

When a user clicks **Complete** for a checklist, Vault does the following:

  * Opens the _Complete Checklist_ dialog and prompts the user to provide any required information and to click **Complete** in the dialog.
  * Completes the workflow task and directs the user to the target object record.

### Entry and User Action to Update Related Aggregate Checklist Design {#update-related-aggregate}

When a checklist design is updated, any related aggregate checklists it belongs to will need to be updated. This action automates that process. Use it as an entry action on the _Superseded_ lifecycle state to update all _Approved_ related aggregate checklists. It can also serve as a user action if any issues occur with the automated job and the process needs to be rerun.

### User Action to Synchronize Lifecycle States of a Checklist Design & Related Records {#sync_lc_states}

If you want a _Checklist Design_ and all of its related records to synchronize to the same lifecycle state after a state change to the _Checklist Design_ record, you can add the _Sync Checklist Design Lifecycle States_ user action. Add this action on the state of the object lifecycle which is the desired final _Checklist Design_ lifecycle state. Users can select only lifecycle states that exist in all related _Checklist Design_ objects.

When creating a _Sync Checklist Design Lifecycle States_ action, you must specify:

  * The _Sync Checklist Design Lifecycle States_ user action
  * The lifecycle state you want to change to (for example: _Draft_)
  * An action label

### User Action to Asynchronously Cascade Delete a Checklist Design {#async_delete}

You can configure the _Delete in Background_ user action to asynchronously delete a checklist design and all the related cascading records, which includes the corresponding section design, question design, available answer design, and dependency design. You can configure this user action for any lifecycle state in the _Checklist Design_ lifecycle; however, users can delete a checklist only when the checklist is in the _Draft_ state, any custom state, and the state associated with the _Initial_ <a href="/en/gr/30683/#state-type">state type</a>.
The difference between the user action option and the standard <a href="/en/gr/52824/#delete">_Delete_ option</a> in the _EDIT_ section of the **Actions** menu (available only for the _Draft_ and _Inactive_ lifecycle states) is that the user action option runs asynchronously and can better handle the deletion of large checklist designs.

Users must have the appropriate delete permission for the _Checklist Design_ object to be able to run the action. The action is not available for any checklist design that you have already used to create a checklist.

## Configuring Welcome Notification Message Templates {#welcome-notifications}

Each _Checklist Type_ in your vault has a corresponding welcome notification message template that users can customize for each _Checklist Design_ record. You can view and edit these message templates from **Admin > Configuration > Notification Templates**, where the message templates are labeled _Welcome: [Target Object]_. To allow checklist designers in your vault to customize welcome notification messages:

  * Configure a <a href="/en/gr/66930/">checklist workflow</a> to include a <a href="/en/gr/33550/#notification">notification step</a> to alert respondents that they are assigned a checklist.
  * Configure the _Checklist Design_ <a href="/en/gr/26387/">page layout</a> to include the _Welcome Email Subject_, _Welcome Email Text_, and _Welcome Notification Text_ fields.
  * Optional: Edit the standard <a href="/en/gr/2157/">object message</a> template for each _Checklist Type_. The object message tokens below reference the fields on the _Checklist Design_ object:

|Checklist Design Field|Object Message Token|
|--- |--- |
|_Welcome Email Subject_|`${Object.welcome_email_subject__sys}`|
|_Welcome Email Text_|`${Object.welcome_notification_text__sys}`|
|_Welcome Notification Text_|`${Object.welcome_email_text__sys}`|

## Related Permissions

In order to complete a checklist, _Edit_ permission is required to the _Target Object Checklist_, _Target Object Response_, and all _Target Object Response_ object types. _Edit_ permission is also required to the following fields on the _Target Object Response_ and its object types:

* _Response Text_
* _Response Number_
* _Response Date_
* _Comments_ _(Rich Text)_

_Create_, _Edit_, and _Delete_ permission to the _Target Object Section_ is required to create, edit, and delete ad hoc sections, and the same permissions are required to the _Target Object Response_ to create, edit, and delete ad hoc questions. The respondent also requires _Create_ and _Delete_ permission to the _Target Object Response Document_ object in order to attach and delete Vault documents from a question or answer.

In addition, you cannot view reference documents attached to questions unless you have _View_ permission to the document.

<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>: It is recommended you have <em>Edit</em> permission to all fields in the <em>Response</em> object and all of its object types.</p>
    </div>
  </div>
</div>





 [1]: #checklist-objects
 [2]: #overview
 [3]: #enabling
 [4]: #matching
 [7]: #objects
 [8]: #design-objects
 [9]: #visual-checklist-designer-fields
 [21]: #initiate_checklists
 [22]: #complete_checklist
 [23]: #sync_lc_states
 [24]: #async_delete
 [32]: #welcome-notifications
 [35]: #update-related-aggregate