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 Vault Support.

Setup Overview

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

Configure Validation Management user actions, such as Author Test, Review Test Script, Start Dry Run, and Review Executed Protocol.

Then, create object data 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 and a naming scheme for Validation Requirements, Test Scripts, and Test Protocol records.

Finally, create Test Scripts 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.

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

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

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

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 Action

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.

To configure this feature:

  1. Add the Validation Deliverable Closure Check shared field 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 state type. 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.

Configuring the Define Executors Workflow Action

Ensure that a Participants Control on the VAL: Test Script Execution Workflow is configured with the custom action: Define Executors. 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

Ensure that a workflow task on the VAL: Test Script Execution Workflow is configured with the custom action: Verify Test Step Completion. 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

When authoring 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, configure the Sync Entity Family Requirement action 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

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.

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

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
  • 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 required to configure this action.

Configuring the Deep Copy Test Script Action

Admins can configure the Deep Copy Test Script user action on any lifecycle state of the Test Script Lifecycle. When a user copies a Test Script, 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

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

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

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 Printable View component.

Configuring the Deep Copy Test Protocol Action

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 Test Step Change process when reassigning the Executor. Vault does not update the completion date/time upon reassignment.

Configuring the Test Script Dry Run Workflow Action

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 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 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 entry criteria to the Pre-Approval state of the Test Script Lifecycle to verify that all comments are in the Resolved or Rejected states.
  • Add entry criteria to the Pre-Approval state of the Test Script Lifecycle to verify whether a test script has dry runs before proceeding to pre-approval.
  • Add entry criteria to the Pre-Approval state of the Test Script Lifecycle to verify that all of a test script’s dry runs are in the Dry Run Complete state.
  • 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, and Test Script Comment records that Vault creates for the purpose of the dry run. Ensure the necessary users have the appropriate permissions to execute this action.

Validation Teams

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 user role.

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

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.

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 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, configure the start step 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 object control permissions 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

Creating Validation 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.

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

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 event action 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 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 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 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 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 re-run 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.

Validation Management Interface Options

Validation Management relies on user interfaces to facilitate the smooth operation of data management and test execution. Configure object lifecycle states that impact 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.