# Configuring Audit Program Planning (QMS)

Using the _Audit Program_ object, audit planners can initiate, plan, and approve audit programs for execution for a determined time 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 _Audits_ and, as the _Audit_ record moves through its lifecycle, related _Proposed Audits_ on the _Audit Program_ record are updated, tracking their execution.

## Configuration Overview

Complete the following configuration steps to take full advantage of Audit Program Planning in your Vault:

  * Configure the [_Audit_ and _Proposed Audit_ objects][1]
  * Configure the _[Audit Program][2] and [Proposed Audit][3]_ object page layouts
  * Add the [_Create Audit Record_][4] entry action to the _Proposed Audit_ object lifecycle
  * Add the [_Create Proposed Audits_][8] action to the _Audit Program_ object and object lifecycle
  * Add the <a href="/en/gr/713617/">_QMS Change Related Object Lifecycle State Job entry action_</a> on _Audit Program_ object lifecycle to track execution in _Proposed Audits_
  * Add _Change State of Related Record_ entry actions on _Audit_ [object lifecycle][5] to track execution in _Proposed Audits_
  * Create [workflows][6] for _Audit Programs_ and _Proposed Audits_
  * Configure [Quality Teams][7] for _Proposed Audits_.

## Audit & Proposed Audit Objects {#audit-objects}

Perform the following object configuration changes on the _Audit_ and _Proposed Audit_ objects.

### Audit & Proposed Audit Fields

In order 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. Vault only copies values for custom (`__c`) fields. 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 that the _Related Audit Program_ and _Related Proposed Audit_ fields on the _Audit_ object are enabled for any _Audit_ object types you wish to use.

### Organization & Proposed Audit Fields

In order for Vault to transfer field data from source _Organization_ records to _Proposed Audit_ records when using the _Create Proposed Audits_ action, you must ensure the field on the _Organization_ and _Proposed Audit_ objects have an identical field _Name_. Object type names must also match exactly.

### Audit & Proposed Audit Object Types

If your processes include any custom object types in addition to _External 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.

## Audit Program Object Page Layout {#audit-program-layout}

Add a related object section on your _Audit Program_ object page layout for related unplanned _Audits_, allowing users to create _Audit_ records and associate them with the _Audit Program_ for reporting purposes. Add another related object section for _Proposed Audits_.

## Proposed Audit Object Page Layout {#proposed-audit-layout}

Add a related object section on your _Proposed Audit_ object page layout for related _Audits_. This will allow users to see the execution status of audits that are directly related to the proposed audit.

## Entry Action: Create Audit Record {#create-audit-record}

Determine the _Proposed Audit_ object lifecycle state that you wish to trigger _Audit_ record creation and add the _Create Audit Record_ entry action. 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 _Audit_ record to be created. 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 be transferred from the _Proposed Audit_ record to the _Audit_ record.

## User Action: Create Proposed Audits {#create-proposed-audits}

The **Create Proposed Audits** user action queries your Vault for applicable _Organizations_ and creates _Proposed Audit_ records with pre-populated data, reducing the need for manual _Proposed Audit_ record creation on an _Audit Program_. The action configuration options define the object type of the resulting _Proposed Audit_ records. They also limit their scope by _Organization_ state and field data criteria, including object type, state, date, and more.

First, add the _Create Proposed Audits_ <a href="/en/gr/43127/">record action</a> on the _Audit Program_ object. When adding the action, ensure that the _Available in All Lifecycle States_ checkbox is not selected.

Then, configure the user action on the _Audit Program_ object lifecycle, in the lifecycle state that the _Audit Program_ should be populated with _Proposed Audits_. _Organization_ filtering options appear after you make selections in previous options, as each higher-order filter determines the lower-order filters available:

  * **Proposed Audit Type**: Select from any configured object type on the _Proposed Audit_ object. The resulting _Proposed Audits_ will have this object type.
  * **Organization Type(s)**: Select one or more configured object types on the _Organization_ object to limit the query to those types.
  * **Required Organization Lifecycle State(s)**: Select one or more lifecycle states on the _Organization Lifecycle_ for which it would be appropriate to create _Proposed Audits_, for example, _Approved_ and other _Approved_-like states.
  * **Associated Organization Date Field**: Select a date field on the _Organization_ object, for example, _Next Scheduled Audit Date_. When the action executes, Vault evaluates if the date on the selected _Organization_ 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.
  * **Allowed Lifecycle States for Duplicate Proposed Audit Creation**: Select one or more states. When the action executes, Vault will not create _Proposed Audits_ for _Organizations_ with an existing associated _Proposed Audit_ record unless all existing records are in one of these states. 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_ previously. Conversely, selecting an _In-Progress_ or _Initiated_ state in this option may result in duplicating an already-active audit.
  * **Included Organization Risk Classifications**: Optionally, select one or more risk classifications to include in Vault's query.

  * **Optional Organization Fields**: Optionally, select up to three (3) additional fields on the _Organization_ object to filter on. You can choose from yes/no, picklist, or related object fields. When the user executes the action, Vault prompts them to select field values to match with when creating _Proposed Audits_.

## Audit Program & Audit Object Lifecycles {#audit-program-audit-lifecycles}

Using _QMS Change Related Object Lifecycle State Job_ and _Change State of Related Record_ entry actions within the _Audit Program_ and _Audit_ object lifecycles, you can ensure that _Proposed Audit_ records move through their lifecycle:

  * Add a _QMS Change Related Object Lifecycle State Job_ entry action on the in-execution _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 State of Related Record_ entry action on states in the _Audit_ object lifecycle to change the state of related _Proposed Audits_, ensuring that the _Proposed Audit_ records move along their lifecycle in parallel with their related _Audits_.

## Audit Program & Proposed Audit Workflow Configuration {#audit-program-proposed-audit-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 per your processes.

Additionally, if you also want to manage the review and approval process on a _Proposed Audit_ record, you can configure a separate workflow. This may be useful in situations where you want to include an additional proposed audit in your _Audit Program_ after it has already been approved. Alternatively, you can create an _Unplanned Audit_ record from the _Audit Program_ record detail page if you do not want to manage a separate review and approval process for _Proposed Audits_.

## Quality Teams for Proposed Audits {#quality-teams}

While you can create custom user fields to define roles, it is recommended that you configure Quality Teams to define role assignments. This will allow those users to be propagated to the corresponding Quality Team role when _Audits_ are created from _Proposed Audits_.

 [1]: #audit-objects
 [2]: #audit-program-layout
 [3]: #proposed-audit-layout
 [4]: #create-audit-record
 [5]: #audit-program-audit-lifecycles
 [6]: #audit-program-proposed-audit-workflow
 [7]: #quality-teams
 [8]: #create-proposed-audits