# Setting Up Validation Management

This article provides best practice information for the configuration of essential pieces of Validation Management, including automation, general data record setup, and team assignments. If you run into problems configuring components or setting up data for Validation Management, contact Veeva Support.

## Setup Overview

Follow these steps to get started in Validation Management. First, ensure that configuration best practices are followed in your Vault and that Validation Management automation and user actions are configured on the appropriate object lifecycle states and workflows:

  * [Create Initial Validation Entity][2]
  * [Create Validation Entity Version][3]
  * [Create Validation Requirement Version][4]
  * [Complete Associated Deliverable Record][10]
  * [Define Executors][5]
  * [Verify Test Step Completion][6]
  * [Calculate Step Numbers][7]
  * [Deep Copy Test Script][18]
  * [Validate Linked Requirements][19]
  * [Author Test][8]
  * [Start Dry Run][17]
  * [Review Authored Test][8]
  * [Execute Test][8]
  * [Pause, Terminate, or Resume Test][8]
  * [Review Test Script][8]
  * [Deep Copy Test Protocol][16]
  * [Review Executed Protocol][9]

Configure Validation Management user actions, such as _Author Test_, _Review Test Script_, _Start Dry Run_, and _Review Executed Protocol_.

Then, create <a href="/en/gr/50533904/#data-model">object data</a> to support validation activities: _Validation Inventory Items_, _Validation Entities_, _Validation Requirements_, _Validation Activities_, and _Validation Deliverables_. When creating _Validation Inventory Items_, you may also define [_Validation Team Assignments_][11] and a [naming scheme][14] for _Validation Requirements_, _Test Scripts_, and _Test Protocol_ records.

Finally, <a href="/en/gr/52308305/">create _Test Scripts_</a> and _Test Protocols_ to fulfill _Testing Deliverables_. Some organizations may prefer to just use stand-alone test scripts and others may prefer to have _Test Protocols_ that are made up of narrative content as well as one or several test scripts.

Organizations that would like their Test Authors to only view approved _Validation Requirements_ in the Requirement Burndown View of the Test Authoring Interface may do so by [configuring object lifecycles][15].

Organizations also can configure standard lifecycle state and state types to automatically redirect users to the appropriate application pages when they click the link for a _Test Script_ or _Test Protocol_ record in a specific lifecycle state. To use this capability, ensure that the **Enable Improved Navigation** feature flag is enabled from the **Admin > Settings > Application Settings** section under **Validation**.

## Validation Management Automation Actions

Validation Management relies on several actions to facilitate the smooth operation of data management and test execution.

### Configuring the Create Initial Validation Entity Action {#create-initial-validation-entity}

Ensure that the _Create Initial Validation Entity_ event action is configured to trigger upon record creation in the _Validation Inventory Item_ lifecycle. This creates a _Validation Entity_ record of a _Validation Inventory Item_ upon creation and ensures that we always have the first instance of an inventory item in the system. Even if the inventory item is an asset that does not have versions, Validation Management relies on having at least one _Validation Entity_ record.

### Configuring the Create Validation Entity Version Action {#create-validation-entity-version}

For entities that are versionable, like _Computer Systems_, ensure that the _Create Validation Entity Version_ action is configured as a user action on the _Validation Entity_ lifecycle in the _Validated_ lifecycle state. This action should be configured with the condition: If **Versionable? > equals > Yes**. This action creates a copy of the previous _Validation Entity_ along with all requirements associated with the previous entity.

### Configuring the Create Validation Requirement Version Action {#create-validation-requirement-version}

Ensure that the _Create Validation Requirement Version_ user action is configured on the _Validation Requirement_ lifecycle in the approved lifecycle state. This action creates a new version of a requirement when an existing requirement needs to be modified.

### Configuring the Complete Associated Deliverable Records Action {#complete-associated-deliverable}

Admins can configure documents to automatically complete associated validation deliverables upon the document reaching a steady state. Only _Validation Deliverable_ records that are not in the _Completed_ or _Cancelled_ states are automatically completed. This entry action also updates the _Vault Document_ field on the _Validation Deliverable_ record while maintaining the latest version in the _Vault Document (Latest)_ field.

The _Complete Associated Deliverable Records_ entry action executes when the _Validation Deliverable_ record transitions to the configured steady state via the workflow. If the state change is available as a user action rather than workflow, the _Validation Deliverable Closure Check_ field should be visible to users. While this field's default security setting is _Hidden_, it should be set to _Read_ or _Edit_.

To configure this feature:

  1. Add the **Validation Deliverable Closure Check** <a href="/en/gr/4884/">shared field</a> to the _Validation_ document type.
  2. Add the **Complete Associated Deliverable Records** entry action to the steady state of the document lifecycle associated with your Vault's _Validation_ document type. For example, if validation documents are associated with the _Draft to Approved_ lifecycle, add the action to the _Approved_ state.
  3. Within the _Validation Deliverable_ lifecycle, associate the _Completed_ state with the _Complete State_ <a href="/en/gr/30683/#state-type">state type</a>. Associate the _Cancelled_ state with the _Cancelled_ state type.
  4. Add the **Vault Document (Latest)** field to the page layout of the desired _Validation Deliverable_ object types.
  5. Recommended: Add entry criteria to the _Completed_ state to check whether at least one document is associated with the _Vault Document (Latest)_ field.

#### Creating a New Draft

Users cannot create a new draft of a document after this entry action runs if:

  * All associated deliverables are in the _Completed_ state.
  * The document type or subtype includes the _Validation Deliverable Closure Check_ field, and the field is set to _Yes_. 

To create a new draft, users must first create a new **Deliverable** record, or reopen the existing _Completed_ record. To create a new draft, users must first create a new **Deliverable** record, or reopen the existing _Completed_ record. Then, in the _Vault Document (Latest)_ field, select the document and open it. From the **Actions** menu, click **Create a New Draft**.

### Configuring the Define Executors Workflow Action {#define-executors}

Ensure that a Participants Control on the _VAL: Test Script Execution Workflow_ is configured with the _Define Executors_ custom action. This action ensures that Executors assigned to perform one or more test steps in a test script only receive one workflow task.

### Configuring the Verify Test Step Completion Workflow Action {#verify-test-step}

Ensure that a workflow task on the _VAL: Test Script Execution Workflow_ is configured with the _Verify Test Step Completion_ custom action. This action ensures that all steps assigned to an Executor are in the _Completed_ lifecycle state before the Executor's workflow task can be completed.

### Configuring the Calculate Step Numbers Action {#calculate-step-numbers}

When users author a test, rearranging steps can result in _Step Number_ field values with long decimal values, which could be confusing to Executors and unwanted in formatted outputs. The _Calculate Step Numbers_ action simplifies the _Step Number_ field values to the appropriate integers. You can configure this action as a user action or as an entry action or both. This action should be configured both on a state prior to, as well as in, the _Pre-Approved_ lifecycle state.

### Configuring the Sync Entity Family Requirement Action

When the family validation feature is enabled, <a href="/en/gr/64158401/">configure the _Sync Entity Family Requirement_ action</a> to help you manage the qualification and validation of either identical or equivalent entities by grouping these assets under a single _Entity Family_ record.

### Configuring the Validate Linked Requirements Action {#validate-linked-requirements}

Admins can configure the _Validate Linked Validation Requirements_ entry action on a lifecycle state of the _Test Script_ lifecycle to ensure that all _Validation Requirements_ linked to a particular _Test Script_ record are in the defined lifecycle states before the test script proceeds to the next state. For example, you might want Vault to check that all linked requirements are in the _Approved_ state before the test can become _Pre-Approved_.

### Configuring the Delete Post-Approval Comments Action

Admins can configure the _Delete Post-Approval Comments_  action as a user action or entry action on an applicable state of the _Test Script_ lifecycle, such as the _Post-Approved_ state, to automatically delete _Test Script Comments_ and _Test Script Comment Replies_ on _Test Scripts_ once they reach post-approval.

## Validation Management User Actions

Validation Management user actions facilitate easy test authoring, test authoring review, test execution, test execution review, and executed protocol review. Ensure that users expected to perform these actions have the appropriate _View_ and _Execute_ permissions in **Admin > Users & Groups > Permission Sets > Object > \[object\] > Object Action Permissions**.

### Configuring the Test Script Lifecycle {#test-script-actions}

Make the following user actions available in the _Test Script_ object lifecycle at the appropriate states:

  * _Author Test_ in the _In Authoring_ (`in_authoring_state__v`) lifecycle state
    * _Default Challenge Status Filter_ for the Requirement Burndown view. _Never Challenged in Validation Entity Version_ is set by default, but Admins can change this setting to another option as needed, such as _Not Challenged inside Validation Activity,_ _Not Challenged outside Validation Activity_, _Challenged inside Test Script_, or _Challenged outside Test Script_.
  * _Review Authored Test_ in the _In Pre-Approval_ (`in_pre_approval_state__v`) lifecycle state. If you configure this action on a lifecycle state other than the standard _In Pre-Approval_ state, the Test Script Review Interface will fail to display the **Review** button.
  * _Execute Test_ in the _In Execution_ (`in_execution_state__v`) lifecycle state
  * _Pause Test_ in the lifecycle state associated with the _In Execution_ (`val_in_execution__v`) state type
  * _Terminate Test_ in the lifecycle state associated with the _In Execution_ (`val_in_execution__v`) state type
  * _Resume Test_ in the lifecycle state associated with the _Execution Paused_ (`val_execution_paused__v`) state type
  * _Review Test Script_ in the _In Independent Review_ (`in_independent_review_state__v`) or the _In Approval_ (`in_approval_state__v`) lifecycle state
  * _Deep Copy Test Script_ in any lifecycle state. There are [additional steps][18] required to configure this action.
  * _Generate Test Step and Discrepancy Attachment Zip_ in any lifecycle state. You may instead wish to configure this action as an entry action.
  * _Delete Post-Approval Comments_ in the _Post-Approved_ (`approved_state__v`) state

### Configuring the Deep Copy Test Script Action {#deep-copy-test-script}

Admins can configure the _Deep Copy Test Script_ user action on any lifecycle state of the _Test Script_ lifecycle. When a user <a href="/en/gr/52308305/#copy-test-scripts">copies a _Test Script_</a>, Vault copies all of its test steps and requirements to the new record; however, Vault only copies _Validation Requirements_ if the chosen _Validation Deliverable_ shares the same _Validation Entity_ as the source _Test Script_. Otherwise, the user receives a warning message that Vault will not copy the requirements.

To configure the _Deep Copy Test Script_ user action:
  
  1. Navigate to the desired lifecycle state of the _Validation Test Script_ lifecycle and add the _Deep Copy Test Script_ user action.
  2. Select a **Target Lifecycle State** from the drop-down.
  3. Optional: If you want Vault to only copy requirements in specific states, select **Copy requirements in specific lifecycle states**. This option is only available if you select _Initiated_ as the **Target Lifecycle State** in the previous step. Select one (1) or more **Requirement Lifecycle States to Include**.
  4. Optional: If you want Vault to allow a user to copy a test script to a new deliverable and test protocol, select **Copy to a new deliverable**.
  5. Populate an **Action Label** according to the target state. For example, a user action labeled **Re-Run Test Script** copies a test script and transitions it to the _Pre-Approved_ (`pre_approved_state__v`) lifecycle state.
  6. Click **Save**.

### Configuring the Review Executed Protocol Action {#review-exe-prot}

Make the _Review Executed Protocol_ action available to users in _Test Protocol_ lifecycle states where approval is taking place, such as _In QA Approval, In Independent Review_, or _In Approval_. An entry criteria is required in these states to check all related test scripts to make sure that they are not in any of the authoring or execution-related lifecycle states, for example, _Draft_, _Pre-Approved_, or _In Execution_.

### Configuring the Import Template Requirement Set Action {#import-template-req-set}

To allow Business Process Owners and System Owners to more efficiently manage requirements, adding multiple requirements to a _Validation Entity Version_ at once, ensure that you add the _Import Template Requirement Set_ record action to the _Validation Entity Version_ object and add it as a user action in the _Validation Entity_ lifecycle. To allow easy setup of the required records for this action, add a _Template Requirements_ related object section to the _Template Requirement Sets_ object page layout.

### Configuring the Generate Printable View Action {#generate-printable-view}

Make the _Generate Printable View_ action available to users in the _Test Script_ lifecycle states where users may need to create a simplified formatted view suitable for printing as a PDF or hard copy. While configuring this action, you must target a <a href="/en/gr/59106401/">_Printable View_ component</a>.

### Configuring the Deep Copy Test Protocol Action {#deep-copy-test-protocol}

Admins can configure the _Deep Copy Test Protocol_ user action on any lifecycle state of the _Test Protocol_ lifecycle to allow users to copy a test protocol with selected test scripts and their associated test steps, prompts, and requirements. Vault only copies _Requirement Traceability Matrix_ records to the new test scripts if the new test protocol shares the same entity version as the original _Test Protocol_ record.

To configure the _Deep Copy Test Protocol_ user action:

  1. Navigate to the desired lifecycle state of the _Validation Test Protocol_ lifecycle and add the _Deep Copy Test Protocol_ user action.
  2. Select a **Target Lifecycle State** from the drop-down.
  3. Optional: If you want Vault to only copy requirements in specific states, select **Copy requirements in specific lifecycle states**. This option is only available if you select _Initiated_ as the _Target_ lifecycle state in the previous step. Select one or more **Requirement Lifecycle States to Include**.
  4. Populate an **Action Label** according to the target state. For example, a user action labeled **Generate New Run** copies a test protocol and creates it in the _Initiated_ (`draft_state__v`) lifecycle state.
  5. Click **Save**.

### Configuring the Reassign Test Step Executor Action

Admins can configure a user action to allow any member of the validation team to reassign a test step from the current Executor or another member of the validation team when a _Test Script_ is _In Execution_. Make the **Reassign Test Step Executor** action available in the following _Test Step_ lifecycle states:

  * _Not Started_ (`not_started_state__v`)
  * _In Progress_ (`in_progress_state__v`)
  * _Completed_ (`completed_state__v`)

When configuring this user action, select the **Use Test Step Change** option to utilize the <a href="/en/gr/50533905/#making-changes">_Test Step Change_ process</a> when reassigning the Executor. Vault does not update the completion date/time upon reassignment.

### Configuring the Test Script Dry Run Workflow Action {#start-dry-run}

Admins can configure a user action to initiate the dry run of a test script before its pre-approval. Add a user action to the standard _In Authoring_ and _Dry Run Authoring Review_ states of the _Test Script_ lifecycle to initiate the _VAL: Test Script Dry Run_ workflow and label it **Start Dry Run**. If you configure this action on a lifecycle state other than the standard _In Authoring_ or _Dry Run Authoring Review_ states, the Test Script Authoring Interface fails to display the _Start Dry Run_ button. Ensure that the necessary users have the appropriate permissions to execute this action.

Perform the following recommended configuration steps in your Vault to accommodate the test script dry run functionality:

  * Add the _Dry Run Required?_ field to the _Test Script_ object page layout. This field indicates whether a test script requires a dry run before proceeding to pre-approval.
  * Add the _Test Script Dry Run?_ field to the _Test Script_ object page layout. This field helps distinguish between dry run test scripts and regular test scripts.
  * Add the _Source Test Script for Dry Run_ object field to the _Test Script_ object page layout. This field relates dry run test scripts to the source _Test Script_ record.
  * Ensure that the necessary users have _Read_ permissions for the above fields.
  * Add the _Dry Run_ related object section to the _Test Script_ object page layout.
  * Add the _Delete Dry Run Results and Comments_ action as an entry action or user action to the appropriate state of the _Test Script_ lifecycle. This action deletes the copies of _Test Step_, _Test Step Additional Prompt_, _Test Script Comment_, and _Test Script Comment Reply_ records that Vault creates for the purpose of the dry run. Ensure that the necessary users have the appropriate permissions to execute this action.

### Configuring the Pause, Resume, and Terminate Test Execution Actions

Admins can configure the _Pause Test Execution_, _Resume Test Execution_, and _Terminate Test Execution_ user actions to pause, resume, or completely terminate a _Test Script_ during execution. When a user pauses, resumes, or terminates a _Test Script_, Vault captures the _Action Type_, _Original State_, _New State_, _Justification_, and _Test Script_ values in the _Test Script Execution Change_ record.

To configure these actions:

1. Add workflows for the _Test Script Execution Change_ object. The end state of a _Test Script Execution Change_ record must match the state configured in the _Completed_ state type.
   1. **Workflows with a task (eSignature)**: Configure the verdict and eSignature as needed. The record must transition to the _Completed_ state when the task is completed.
   2. **Workflows without a task**: The record must transition to the _Completed_ state.
2. Configure the _Validation Test Script Change_ lifecycle.
   1. Add and map states for the _Initial State_, _Complete State_, and _Cancelled_ state types.
   2. Configure the user actions to start the workflow in the _Initial State_. Admins can decide which workflow is used for which action, such as configuring a workflow with a task like an eSignature for the _Resume Test Execution_ and _Terminate Test Execution_ actions and configuring a workflow without a task for the _Pause Test Execution_ action.
3. Configure the _Validation Test Script_ lifecycle.
   1. Add and map states for the _Initial State_, _Complete State_, _Execution Paused_, _Execution Terminated_, and _In Execution_ state types.
   2. Add the _Pause Test Execution_ and _Terminate Test Execution_ actions to the _In Execution_ state.
   3. Add the _Resume Test Execution_, _Terminate Test Execution_, and _Execute Test_ actions to the _Execution Paused_ state.
4. Ensure that users have _Create_ permissions assigned for the _Test Script Execution Change_ and the _Test Script Execution Change Signature_ objects.
5. Configure an entry action to change the state of the test steps when a _Test Script_ is paused or terminated. If the _Test Script_ is terminated, Vault should move the test steps to the _Completed_ state.

## Validation Teams {#validation-team-assignments}

Validation Teams define how permissions apply across records in the Validation Management application. Users with _Validation Team Assignment_ records associated with a _Validation Inventory Item_ are granted record visibility access rights to all validation-related object records that share the same _Validation Inventory Item_.

Vault provides the following system-managed _Validation Team Roles_:

  * **Business Process Owner**: The individual who owns and manages the business process for the _Validation Inventory Item_. This role gives _Read_, _Create_, _Edit_, and _Delete_ permissions for the _Validation Inventory Item_ and _Validation Entities_ and the _Read_ permission for all records associated with the _Validation Inventory Item_.
  * **Quality Assurance**: The individual from the Quality Unit who provides necessary reviews and approvals related to the _Validation Inventory Item_. This role gives the _Read_ permission for all records associated with the _Validation Inventory Item_.
  * **System Owner**: The individual who owns and manages the _Validation Inventory Item_. This role gives _Read_, _Create_, _Edit_, and _Delete_ permissions for the _Validation Inventory Item_ and _Validation Entities_ and the _Read_ permission for all records associated with the _Validation Inventory Item_.
  * **Validation Contributor**: The individual who participates in the validation project as a member for the _Validation Inventory Item_. This role gives _Read_ permission for all records associated with the _Validation Inventory Item_.
  * **Validation Lead**: The individual who leads the validation project for the _Validation Inventory Item_. This role gives the _Edit_ permission for the _Validation Inventory Item_ and _Validation Entities_.

Users who require view access to all validation records should be assigned as Validation Viewer through their <a href="/en/gr/69197/#assigning">user role</a>.

### Configuring Page Layouts

Before incorporating a validation team into your existing business process, configure the following object page layouts to accommodate this feature:

  1. Add the _Validation Team Assignment_ object as a related object section on all _Validation Inventory Item_ object type page layouts.
  2. Add a _Validation Application User control_ for the owner fields on the page layouts of the following objects: _Validation Requirement_, _Validation Activity_, _Validation Deliverable_, _Test Protocol_, _Test Script_, _Test Step_, and _Discrepancy_. For example, the page layout for the _Validation Requirement_ object should have a user control for the _Requirement Owner_ field. Remove existing owner fields from the page layout to avoid confusion.
  3. Optional: Add a _User control_ for the _Co-Authors_ field on the page layout of the _Test Script_ object.
  4. Optional: Ensure that the _Validation Inventory Item_ field exists on the page layouts of the following objects: _Validation Requirement_, _Validation Activity_, _Validation Deliverable_, _Test Protocol_, _Test Script_, _Test Step_, _Discrepancy_, _Test Script Execution Change_, and _Test Step Change_.
  5. Optional: Add the _Role Dependency_ and _Validation Team Assignment_ objects as  related object sections on the _Validation Team Role_ page layout.

### Configuring Object Lifecycles {#val-team-object-lifecycles}

Before incorporating a Validation Team into your existing business process, configure the following object lifecycles to accommodate this feature:

  1. Add the _Assign Record Creator to Validation Team Role_ action to the _Create Record_ event on the _Validation Inventory_ lifecycle. Indicate a _Validation Team Role_ that the record creator is assigned to.
  2. Add the system-managed application roles to the lifecycles of the following objects: _Validation Inventory Item_, _Validation Entity_, _Validation Requirement_, _Validation Activity_, _Validation Deliverable_, _Test Protocol_, _Test Script_, _Test Script Execution Change_, _Test Step_, _Test Step Change_, and _Discrepancy_.

<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>: Remove the <em>Assign Record Creator to Validation Team Role</em> event action temporarily until migration activities are complete. Once you configure the event action, a record creator is automatically assigned to the <em>Validation Inventory Item</em> and a single user cannot have more than 500 <em>Validation Inventory Item</em> records.</p>
    </div>
  </div>
</div>



### Configuring Workflows

You can configure your workflow start steps to use roles from Validation Teams as workflow participants. The workflow retrieves users from roles through [Validation Team Assignment][13] as well as standard user reference fields such as _Requirement Owner_, _Activity Owner_, _Deliverable Owner_, _Author_, _Co-Authors_, _Executor_, and _Discrepancy Owner_.

To use roles from Validation Teams as workflow participants, <a href="/en/gr/33550/#participants-control">configure the start step</a> with either the **Allow workflow initiator to select participants** or **Use roles as participants** options.

Vault does not support multi-record workflows for the _Test Script_ lifecycle and the _Test Protocol_ lifecycle. When configuring these workflows, ensure that **Use workflow for single object record** is selected.

### Configuring Permissions

Ensure that the desired users have the following object permissions added to their security profile:

  * _Validation Team Assignment_: Read, Create, Edit, Delete
  * _Validation Team Role_: Read
  * _Role Dependency_: Read

Ensure that the desired users have the following <a href="/en/gr/22824/#object-control-permissions">object control permissions</a> for the _Validation Application User control_ added to their security profile:

  * _Validation Requirement_: Read
  * _Validation Activity_: Read
  * _Validation Deliverable_: Read
  * _Test Protocol_: Read
  * _Test Script_: Read
  * _Test Step_: Read
  * _Discrepancy_: Read

### Managing Validation Team Warnings

There may be situations where you do not want Vault to display _Validation Team Assignment_ warnings. To disable warnings for a specific field and lifecycle state:

  1. Navigate to **Admin > Configuration > Application Configurations > Quality Configurations > Validation Team Warning Controls**.
  2. Click **Create**.
  3. Select an **Object**.
  4. Select a **Field**. 
  5. Select one or multiple **Lifecycle States**.
  6. Click **Save**.

### Creating Validation Team Assignments {#creating-val-team-assignments}

To assign users to a team role:

  1. Navigate to a custom object tab for _Validation Inventory Items_ or **Business Admin > Objects > Validation Inventory Items** and select a record.
  2. In the _Validation Team Assignments_ section, click **Create**.
  3. Select a **User** and assign them a **Validation Team Role**.
  4. Click **Save**.

#### Constraining Roles

You can filter the list of users displayed when performing Validation Team Assignments by constraining roles using:

  * <a href="/en/gr/33946/">Dynamic Access Control</a> (DAC)
  * The _Constraining Application Role_ field and _Constraining Role Field App Control_ on the applicable _Validation Team Role_
  * The _User Field App Control_ on the applicable _Validation Team Assignment_

To do this, you must first add the _Constraining Role Field App Control_ and the _User Field App Control_ fields to the applicable object's page layout.

### Limitations

Keep the following limitations in mind when working with _Validation Team Assignments_:

  * A user can be assigned to a _Validation Team Role_ on a maximum of 500 _Validation Inventory Item_ records.

## Validation Management Test Co-Authors

There may be scenarios where your organization requires multiple Test Co-Authors to author test steps within the same _Test Script_. Perform the following configuration in your Vault to accommodate the Test Co-Author capability.

### Configuring Page Layouts

To configure the _Test Script_ page layout to accommodate Test Co-Authors:

  1. Navigate to **Admin > Configurations > Objects > Test Script > Layouts**.
  2. Add a field control for Co-Authors.

### Configuring Object Lifecycles

To configure the _Test Script_ object lifecycle to accommodate Test Co-Authors:

  1. Add the Validation Test Co-Author role to the _Test Script_ lifecycle and give _Edit_ permission to applicable states, such as _In Authoring_. Configure the atomic security settings for the Validation Test Co-Author role for applicable states.
  2. Add the Validation Test Co-Author role to the _Test Step_ lifecycle and give _Edit_ permission to applicable states, such as _In Authoring_. Configure the atomic security settings for the Validation Test Co-Author role for applicable states.
  3. Add the Validation Test Co-Author role to the _Test Step Additional Prompt_ lifecycle and give _Edit_ permission to applicable states, such as _In Authoring_. Configure the atomic security settings for the Validation Test Co-Author role for applicable states.

### Configuring Workflows

You can configure the start steps for applicable workflows to include Test Co-Authors as workflow participants. Configure the participant control with **Use roles as participants** and add the Validation Test Co-Author role to the **Roles allowed to participate**.

### Configuring Permissions

Ensure that users expected to be Test Co-Authors have _Read_, _Create_, _Edit_, and _Delete_ permissions added to their security profile for the _Test Co-Author_ object.

## Naming Schemes {#naming-schemes}

You can configure naming schemes to automatically manage the generation of a unique name for _Validation Requirements_, _Test Script_, and _Test Protocol_ records based on a predefined format, regardless of requirement version or test script run number.

The format for naming _Validation Requirements_ is determined by combining the values of the _Entity Acronym_, _Requirement Type Acronym_, _Suffix_, and _Sequence Number_ fields. For example, Vault may assign a requirement's _Name_ to be `VAL-UR-MECH-0001`.

The format for naming _Test Scripts_ and _Test Protocols_ is determined by combining the values of the _Entity Acronym_ and _Sequence Number_ fields with "TS" or "TP". For example, Vault may assign a test script's _Record Number_ to be `VAL-TS-001` and a test protocol's _Record Number_ to be `VAL-TP-001`.

### Configuring Object Fields

Enable the following fields for all object types on the indicated object in order to support the naming scheme capability:

  * _Entity Acronym_ (`entity_acronym__v`) on the _Validation Entity_ (`val_inventory_item__v`) object. Enable the _User must always enter a value (required)_ option.
  * _Name_ (`name__v`) on the _Validation Requirement_ (`val_requirement_svo__v`) object. Disable the _Values must be unique_ and _System manages field value (read-only)_ options.
  * _Requirement Suffix_ (`requirement_suffix__v`) on the _Validation Requirement_ (`val_requirement_svo__v`) object.
  * _Requirement Type Acronym_ (`requirement_type_acronym__v`) on the _Validation Requirement_ (`val_requirement_svo__v`) object. Assign the _Requirement Type Acronym_ field a default value of `UR` for each object type.
  * _Uniqueness Key_ (`uniqueness_key__v`) on the _Validation Requirement_ (`val_requirement_svo__v`) object.
  * _Legacy Requirement ID_ (`legacy_requirement_id__v`) on the _Validation Requirement_ (`val_requirement_svo__v`) object.
  * _Record Number_ (`name__v`) on the _Test Script_ (`val_test_script_svo__v`) object. Disable the _Values must be unique_ and _System manages field value (read-only)_ options.
  * _Record Number_ (`name__v`) on the _Test Protocol_ (`val_test_protocol_svo__v`) object. Disable the _Values must be unique_ and _System manages field value (read-only)_ options.

### Configuring Object Lifecycles

Add the following <a href="/en/gr/51700/#object-event-actions">event action</a> rules to the _Create Record_ event on the appropriate object lifecycles to support the naming scheme capability:

  * _Set Requirement Name_ action on the _Validation Requirement_ lifecycle
  * _Set Test Script Name_ action on the _Test Script_ lifecycle
  * _Set Test Protocol Name_ action on the _Test Protocol_ lifecycle

When a user creates a _Validation Requirement_, _Test Script_, or _Test Protocol_ record, Vault populates the name of the record according to the predefined naming schemes.

### Enabling Naming Scheme Migration

Vault can perform a job to migrate the IDs of existing _Validation Requirement_, _Test Script_, and _Test Protocol_ records to legacy ID fields and populate the _Record Number_ and _Name_ fields according to the predefined naming schemes.

Before initiating the naming scheme migration:

  1. Ensure that the _Entity Acronym_ field is populated for all _Validation Entity_ records. If this field is blank, Vault will not include the _Entity Acronym_ in the generated name.
  2. Ensure that the _Requirement Type Acronym_ and _Requirement Suffix_ fields are populated for all _Validation Requirement_ records. If this field is blank, Vault will not include the _Requirement Type Acronym_ in the generated name.
  3. Ensure that the _Test Script ID_ field is populated for all _Test Script_ records. If this field is blank, the migration job will fail. If you want multiple _Test Scripts_ to share the same name, records can share the same _Test Script ID_ but must have different _Run Numbers_.
  4. Ensure that the _Test Protocol ID_ field is populated for all _Test Protocol_ records. If this field is blank, the migration job will fail. If you want multiple _Test Protocols_ to share the same name, records can share the same _Test Protocol ID_ but must have different _Run Numbers_.

To run the naming scheme migration:

  1. Navigate to **Admin > Configurations > Validation Naming Scheme Migration**.
  2. From the drop-down, indicate an **Object to Migrate**.
  3. Optional: Select any applicable **Lifecycle states to exclude** from the migration.
  4. Click **Run Migration**.

Following the migration, the _Requirement ID_, _Test Script ID_, and _Test Protocol ID_ fields on the respective objects are read-only. After the first successful migration, you can rerun the migration job but it will only migrate ID field values to the legacy ID fields.

On the _Validation Naming Scheme Migration_ page, you can only view up to six (6) migration job histories. If you want to see more, navigate to **Admin > Operations > Job Status** and click **View All** from the right bottom side of the _History_ table.

## In-Scope Requirements & Specifications for Validation Activities

With the **In-Scope Requirements & Specifications for Validation Activity** feature, users can define which requirements and specifications are in scope and which need to be challenged for a _Validation Activity_, rather than a _Validation Entity_. If multiple _Validation Activities_ are involved, this feature provides improved clarity regarding which requirements and specifications are applicable for the validation process.

This feature adds a _Validation Activity_ field to the _Requirement Traceability Matrix_ (`val_rtm_svo__v`) object. If your _Requirement Traceability Matrix_ records are linked to _Test Steps_ already, Vault automatically populates the _Validation Activity_ field with the _Validation Activity_ that the _Test Step_ is associated with. When the requirement or specification is challenged, the _Validation Activity_ field is updated automatically as well. This process also allows users to immediately see which requirements and specifications are included for a _Validation Activity_ directly in their Traceability Matrix reports.

### Configuring Page Layouts

To support this functionality, add the _Activity Requirements_ app section to the _Validation Activity_ page layout. This section allows users to create or link requirements and specifications and exclude requirements and specifications that no longer are in scope.

### Configuring Objects and Object Fields

Enable the following objects and fields on the indicated object to support this functionality:

* Enable the _Test Strategy Justification_ text field on all object types of the _Validation Requirement_ object. When users select **Testing Not Required**, Vault also allows them to provide a justification for compliance purposes.
* Update permission sets for the _Validation Activity_ object reference and the _Test Strategy_ field on the _Requirement Traceability Matrix_ (`val_rtm_svo__v`) object.

### Configuring Permissions

Ensure that users have _Edit_ permission for the _Validation Activity_ (`validation_activity__v`) field on the _Requirement Traceability Matrix_ (`val_rtm_svo__v`) object.

## Validation Management Interface Options {#interfaces}

Validation Management relies on user interfaces to facilitate the smooth operation of data management and test execution. You can configure object lifecycle states that affect these interfaces in order to assist in your organization's processes.

### Test Authoring Interface

By default, the Requirement Burndown View displays all requirements regardless of their lifecycle state. To filter the Requirements Burndown View on the Test Authoring Interface to only display requirements of a particular lifecycle state, associate the desired lifecycle state with the _Approved_ state type within the _Validation Requirement_ lifecycle. If a lifecycle state is not associated with the _Approved_ state type, then the Requirement Burndown View displays all requirements regardless of their lifecycle state.

### Automatic Navigation to Test Authoring, Execution, and Review Interfaces

If configured by an Admin, Vault can automatically redirect users to the appropriate Validation Management application page, like the Test Execution Interface, when they click the link for a _Test Script_ or _Test Protocol_ record in a specific lifecycle state and have an assigned task listed on the record. For example, if a user clicks the _Test Script_ record link while the record is in the _In Authoring_ lifecycle state, Vault redirects the user to the Test Authoring Interface to address their assigned task. If <a href="/en/gr/50533904/#minimum-permissions">minimum permissions</a> are not assigned, users see an error message instead of the intended application page. If the user does not have an open workflow task, they will be redirected to the Vault object record detail page instead of the application page.

If <a href="/en/gr/59106401/">_Printable Views_</a> are configured, Vault does not redirect users to an application page when they open a _Test Script_ record to its _Printable View_. Users are returned to the record detail page after they access the _Printable View_ and then click **Close**.

### Filtering Comments by Lifecycle State

If configured by an Admin, Vault allows Test Script Authors and Dry Run Executors to filter comments in the Comments View by lifecycle state. Users can click the filter icon, change the filter from all default comment states to one or more states, and click **Apply** to review comments in specific lifecycle states. Admins can configure which _Test Script Comment_ (`val_test_script_comment_lifecycle__v`) lifecycle states should be selected by default for filtering comments in the Test Dry Run and Test Author Interfaces on the associated user actions. If no states are selected, all states are displayed when a user clicks the filter icon.

### Test Script and Test Protocol Execution Review Comments

If configured by an Admin, Vault can allow reviewers to provide targeted feedback at a step or prompt level when reviewing and approving the execution of _Test Scripts_ or _Test Protocols_. For _Test Scripts and Test Protocols_, reviewers can identify steps that require re-execution by adding comments with a re-execution flagged category, and Executors can address feedback and reply as necessary. For _Test Protocols_, Executors can respond to feedback and resolve questions at the test script level.

#### Test Script Execution Review Comments

To configure this feature:

* Add permissions to the existing permission sets for the _Post-Approval Comment_ object type in the _Validation Test Script Comment_ object and the _Validation Test Script Comment Reply_ and _Test Script Comment Category_ objects.
* Enable the _Post-Approval Comment_ object type in the _Validation Test Script Comment_ object.
* Add _Test Script Comment Category_ records to the _Test Script Comment Category_ object.
* Review and configure state and role permissions for the _Validation Test Script Comment_ and _Validation Test Script Comment Reply_ lifecycles.

#### Test Protocol Execution Review Comments

To configure this feature:

* Add the Comment View to the Test Protocol Review Interface.
* Add the _Reject Test Scripts with Re-execution Required Comments_ entry action to the _Test Protocol Rejected_ lifecycle state to move _Test Scripts_ with open re-execution flagged comments to a _Rejected_ state.
* Add the _VAL: Test Script Re-Execution for Protocol_ standard workflow to the _Test Script_ lifecycle.

### Optional Entity Versions

If configured by an Admin, Vault allows users to manage non-versionable _Validation Entities_ more efficiently for activities, deliverables, requirements, specifications, and so on. To utilize this feature, Admins can add the Entity Requirement app section to the _Validation Entity_ page layout, allowing for the management of requirements at the entity level, or add app control fields to the _Validation Entity_ object layout, allowing for the viewing and editing of entity version fields at the entity level.

If configured, the _Validation Entity Version_ information is visible when appropriate. This allows users to change a versionable _Validation Entity_ to a non-versionable _Validation Entity_ and see the appropriate related content. When a user changes an _Entity_ to non-versionable, Vault uses the _Latest Entity Version_ identified on the _Entity_ as the primary version behind the scenes. If not configured, _Entity Versions_ and _Entities_ behave as they have previously.

To configure this feature:

* Add the Entity Requirements app section to the _Validation Entity_ page layout to ensure that users can create and manage requirements at the entity level.
* Add the _Entity Version Field App Control_ field to the _Validation Entity_ object layouts, and select the _Entity Version Relationship_ and _Entity Version Field Name to Control_ options. This ensures that users can review and update the entity version from the field on the _Validation Entity_ record.
* Determine if any changes are required for the states and workflows for the _Validation Entity_ lifecycles.
* Add the _Import Template Requirement Set_ action to the appropriate _Validation Entity Lifecycle_ states.
* Optional: Modify the _Val: Entity Req File Gen Success_, _Val: Entity Ver Req File Gen Success_, and _Val: Activity Req File Gen Success_ <a href="/en/gr/2157/">notification templates</a>.

  [1]: #automation-actions
  [2]: #create-initial-validation-entity
  [3]: #create-validation-entity-version
  [4]: #create-validation-requirement-version
  [5]: #define-executors
  [6]: #verify-test-step
  [7]: #calculate-step-numbers
  [8]: #test-script-actions
  [9]: #review-exe-prot
  [10]: #complete-associated-deliverable
  [11]: #validation-team-assignments
  [12]: #val-team-object-lifecycles
  [13]: #creating-val-team-assignments
  [14]: #naming-schemes
  [15]: #interfaces
  [16]: #deep-copy-test-protocol
  [17]: #start-dry-run
  [18]: #deep-copy-test-script
  [19]: #validate-linked-requirements