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 workflow 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 Designing Checklists.

How to Enable Checklists for an Object

You can enable checklist types for any system, standard, or custom object. To do this:

  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.
  6. To enable Version Control for the Checklist Type, select Yes.
  7. Click Save.

Default Configuration

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

Workflows

See Configuring Checklist Workflows.

Configuration 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 Checklist Design Loader for more details.

To configure a checklist:

  • Optional: Configure object layouts 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: Configure object layouts for Checklist Design to show child Checklist Design Translation and Checklist Field Translation records.
  • Define picklist options for the Checklist Type picklist.
  • Create a Checklist Design object record. 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 aggregating two or more approved checklist designs. You can also create a Checklist Design record by copying an existing checklist design. 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 new version of an existing checklist design.
  • Once you save a new Checklist Design record or select an existing Checklist Design from the object record list page, Vault directs you to the Visual Checklist Designer. You can use this tool as an alternative to the Checklist Design Loader or the traditional checklist design options. If the Checklist Design is an aggregate checklist, Vault directs you to the Checklist Design record detail page instead.
  • Create one or more Section Design records. 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 sub checklists instead of question sections.
  • Create the series of Question Design records. Each record represents a single question. 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 question guidance text and reference documents.
  • Create Dependency Design records 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.
  • Configure lifecycle state entry actions and/or lifecycle state user actions to initiate a checklist response within the lifecycle configuration for the related object.
  • Optional: Configure the object page layout for the target object to show related Checklist records.
  • Configure lifecycle state entry actions 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 layout. 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 Dynamic Access Control (DAC) 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 layout. 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 Dynamic Access Control (DAC) assignments, to add ad hoc sections to a checklist.
  • Optional: Configure welcome notification messages that Vault will send to respondents assigned to complete a checklist.
  • Optional: Configure optional fields to display on the Visual Checklist Designer.

Objects Supporting Checklists

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

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.

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.
  • 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.

Setting up Questions and Answers

See Checklist Question & Answer Setup.

Matching Fields

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.

Visual Checklist Designer Fields

The Checklist Types page displays the optional and required fields for the Visual Checklist Designer. 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.

Checklist Type (Picklist)

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:

Entry & User Actions to 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’ Accepted workflow. If you configure the Start Checklist action as an entry action, ensure you configure the ‘target object’ Pending Acceptance workflow. Note that 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 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 state type.

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 aggregate 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.

User Action to Complete Checklists

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

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

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

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 state type. The difference between the user action option and the standard Delete option 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

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 checklist workflow to include a notification step to alert respondents that they are assigned a checklist.
  • Configure the Checklist Design page layout to include the Welcome Email Subject, Welcome Email Text, and Welcome Notification Text fields.
  • Optional: Edit the standard object message 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}