QualityOne Vaults allow you to determine and conduct audits in a given period under a specified scope by creating audit program plans. Using the Audit Program object, audit planners can initiate, propose, and approve audit programs for execution for a determined period. Once the Audit Program record enters a specified state, Vault automatically creates Audit object records based on Proposed Audit record data within the Audit Program. Users can then conduct, update, and track the execution of Audits and related Proposed Audits (while the Audit record moves through its lifecycle) on the Audit Program record.

Audit Program Planning Objects

QualityOne uses the following core objects and object types to support Audit Program Planning:

  • Audit (audit__qdm): This object represents audits.
    • Internal Audit (internal_audit__qdm): This Audit object type represents internal audits.
    • Supplier Audit (supplier_audit__qdm): This Audit object type represents supplier audits.
  • Audit Program (audit_program__v): This object represents audit programs and their associated proposed audits where they’re initiated, reviewed, and approved.
  • Proposed Audit (proposed_audit__v): This object represents the proposed audits planned as part of an audit program.
    • Internal Audit (internal_audit__v): This Proposed Audit object type represents internal proposed audits.
    • Supplier Audit (supplier_audit__v): This Proposed Audit object type represents external supplier proposed audits.

Configuration Overview

Configuring your Vault to use Audit Program Planning involves the following steps:

  1. Configure the audit program planning objects
  2. Configure the audit program planning object layouts
  3. Configure actions for audit program planning object lifecycles
  4. Create workflows for audit program planning objects
  5. Configure Teams for Proposed Audits
  6. Configure user permissions

Configuring Audit Program Planning Objects

Perform the following object configuration changes on the Audit and Proposed Audit objects.

Audit & Proposed Audit Fields

For Vault to transfer field data from source Proposed Audit records to Audit records, you must add the field to the Proposed Audit object with an identical field Name. Object type names must also match exactly. For example, to transfer the Executive Summary (executive_summary__c) field value, a field with an identical Name value (executive_summary__c) must exist on both objects.

Ensure you enable the Related Audit Program and Related Proposed Audit fields on the required Audit object types.

Audit & Proposed Audit Object Types

If your processes include any custom object types in addition to Supplier Audit and Internal Audit, you must configure those object types for both Audit and Proposed Audit objects. The Name of the object type must match exactly between the Audit and Proposed Audit object types.

Configuring Object Layouts

We recommend updating object layouts for the following objects:

  • For the Audit Program object:
    • Related Object Section: Insert the Audit (audit__qdm) object for the related unplanned Audits. We recommend using the section label “Unplanned Audits”.
    • Related Object Section: Insert the Proposed Audit (proposed_audit__v) object.
  • For the Proposed Audit object:
    • Related Object Section: Insert the Audit (audit__qdm) object. We recommend using the section label “Related Audits”.

Configuring Actions for Audit Program Planning

Perform the entry action configurations on the Audit and Proposed Audit object lifecycles for the Create Audit Record and Change related object lifecycle state entry actions.

Configuring the Create Audit Record Action

You must configure the Create Audit Record entry action for Vault to automatically create an Audit record when the Proposed Audit enters a specific lifecycle state. Determine the Proposed Audit object lifecycle state needed to trigger Audit record creation and add the Create Audit Record entry action. We recommend an approved lifecycle state. The optional field-mapping selection boxes allow you to map the Auditee, Planned Start Date, and Planned End Date standard fields to corresponding fields on the created Audit record. The drop-downs only display fields with the appropriate field type, for example Organization or Date. If you leave the drop-downs blank, data for those fields will not transfer from the Proposed Audit record to the Audit record.

Configuring the Create Proposed Audits User Action

The Create Proposed Audits user action queries your Vault for applicable Facilities or Organizations and creates up to 500 Proposed Audit records with pre-populated data from the Facility or Organization records, reducing the need for manual Proposed Audit record creation on an Audit Program. The action configuration options define the object type of the created Proposed Audit records and limit the scope of Proposed Audit creation by Facility or Organization lifecycle state and field data criteria, including object type, lifecycle state, date, and risk classification.

To configure this action:

  1. Ensure sharing settings are enabled on the Audit Program and Proposed Audit objects.
  2. Ensure the Proposed Audit object has an object field that references either the Organization or Facility object.
  3. Add the Create Proposed Audits action to the Audit Program object. When adding the action, do not select the Available in All Lifecycle States checkbox.
  4. Add the Create Proposed Audits user action on the Audit Program object lifecycle, in the lifecycle state that the Audit Program should be populated with Proposed Audits. Additional fields appear as you make selections, as each field value determines the subsequent fields available for configuration.
  5. Select a Proposed Audit Type from any active object type on the Proposed Audit object. The created Proposed Audits will be this object type.
  6. Select the Source Object Reference Field, an object field on the Proposed Audit object that references either the Facility or Organization object. Your selection determines if Vault creates Proposed Audits from either Facility or Organization records when users run this action.
  7. Select one (1) or more Source Object Type(s) on the object you selected as the Source Object Reference Field to limit the Proposed Audits created to specific types of Facility or Organization records.
  8. Select one (1) or more Source Object Lifecycle State(s) on the Organization Lifecycle or Facility Lifecycle for which it is appropriate to create Proposed Audits (for example, Approved and other similar Approved states).
  9. Select a Source Object Date Field. This is a date field on the Organization or Facility object, for example, Next Scheduled Audit Date. When the action executes, Vault evaluates if the date on the selected Organization or Facility is between the Planned Start Date and Planned End Date on the Audit Program record. If it is, then Vault selects the record for Proposed Audit generation.
  10. Select one (1) or more Allowed Lifecycle States for Duplicate Proposed Audit Creation. When the action executes, Vault will not create Proposed Audits for Organizations or Facilities with an existing associated Proposed Audit record unless all existing records are in a state specified in this field. For example, you might select Complete or Canceled states to ensure that Vault still creates Proposed Audit records when the action executes, even though other Audits have been processed for this Organization or Facility previously. Conversely, selecting an In-Progress or Initiated state in this option may result in duplicating an already-active audit.
  11. Optional: Select one (1) or more Source Object Risk Classification(s) to include in Vault’s query.
  12. Optional: Select up to three (3) Source Object Optional Field(s) to filter on. These are Yes/No, picklist, or related object fields on the Organization or Facility object. When the user executes the action, Vault prompts them to select field values to match with when creating Proposed Audits.
  13. Enter an Action Label.
  14. Click Save.

You may use the Change related object lifecycle state entry action within the Audit Program and Audit object lifecycles to ensure that Proposed Audit records move through their lifecycle. You can:

  • Add the Change related object lifecycle state entry action on an Audit Program object lifecycle state to change the state of related Proposed Audits to the triggering state for the Create Audit Record entry action.
  • Add the Change related object lifecycle state entry action on an Audit object lifecycle state to change the state of related Proposed Audits, ensuring that the Proposed Audit records move along their lifecycle in parallel with their related Audits.

Creating Audit Program Planning Workflow

If you want to include a review and approval workflow as part of your Audit Program Planning process, you must create and configure one (1) workflow for each process.

Additionally, to manage the review and approval process on a Proposed Audit record, you can configure a separate workflow. Using separate workflows may help in situations where you require an additional proposed audit in your Audit Program after approval. Alternatively, you can create an unplanned Audit record from the Audit Program record detail page to avoid managing a separate review and approval process for Proposed Audits.

Configuring Teams for Proposed Audits

While you can create custom user fields to define roles, we recommend that you enable Teams for the Proposed Audit object to define role assignments for the related Audit records. Using Teams allow Vault to generate the defined users, corresponding to the Team Role when creating Audits from Proposed Audits for the Audit Program record.

Configuring User Permissions

You must ensure users have the appropriate read and create permissions to access the appropriate objects and object fields in addition to the permissions outlined below:

  • For the Audit Program object: Read, Create, and Edit permission
  • For the Proposed Audit object and its object types: Read, Create, and Edit permission
  • For the Create Proposed Audits user action: Read permission on any related object field for which users must select values to run the action

You can complete all the steps in this article with the standard System Administrator or Vault Owner security profile. If your Vault uses custom security profiles, your profile must grant the following permissions:

Type Permission Controls
Security Profile Admin: Configuration: Object Lifecycles: Create, Edit Ability to create and modify object lifecycles.
Security Profile Admin: Configuration: Objects: Create, Edit Ability to create and modify Vault objects.
Security Profile Admin: Security: Permission Sets: Edit Ability to modify permission sets for users.
Security Profile Admin: Settings: General Information: Edit Ability to modify settings in the Vault General Settings page.