# Configuring Audit Program Planning (HSE, QMS)

<!--QMS Audit Management Admin section-->

<!--Source File, original slug /74361/-->



[QualityOne Vaults](/en/lr/78610/) allow you to determine which [audits](/en/lr/650396/) to conduct within a specified time period and scope by creating [audit program plans](/en/lr/650412/). Audit planners can initiate, propose, and approve audit programs from an _Audit Program_ record. Once the _Audit Program_ record enters a specified state, Vault automatically creates _Audit_ records based on the _Proposed Audits_ in the audit program. Users can then conduct the _Audits_ and track their progress from the _Audit Program_ record.

## Configuration Overview {#overview}

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

1. [Configure the audit program planning objects][1]
2. [Configure the audit program planning object layouts][2]
3. [Configure actions for audit program planning object lifecycles][7]
4. [Create workflows for audit program planning objects][5]
5. [Configure Teams for _Proposed Audits_][6]
6. [Configure user permissions][8]

<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>: Depending on your Vault’s creation date and which features are currently enabled and configured, some of the steps described in this article may be unavailable or already complete in your Vault.</p>
    </div>
  </div>
</div>



## Configuring Audit Program Planning Objects {#configuring-objects}

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

### Proposed Audit Fields {#fields}

When users run the [_Create Proposed Audits_ action][9], Vault populates required fields on the created _Proposed Audit_ records with field data from the target _Organization_ record (for supplier audits) or _Facility_ record (for internal audits). For Vault to transfer data between the correct fields, ensure the value of the _Name_ attribute for required fields on the _Proposed Audit_ object matches the _Name_ attribute value of fields on the _Organization_ and _Facility_ objects. If Vault cannot find an exact match or if an exact match exists but the field is inactive or empty, Vault searches for the closest match, prioritizing fields with a different [namespace](/en/lr/22904/#namespace) suffix (for instance, `__v`) but otherwise identical field name. For example, Vault transfers the _Address_ (`address__v`) field value on the _Organization_ to the _Facility Address_ (`address__c`) field on the _Proposed Audit_.

Vault only transfers data between the same field types. The following field types can be populated:

* _Boolean_
* _Date_
* _DateTime_
* _Number_
* _Object_ (_Object_, _Parent Object_)
* _Picklist_
* _Text_ (_Long Text_, _Rich Text_, _Text_)

### Audit Fields {#audit-fields}

When the [_Create Audit Record_ action][3] runs, Vault populates fields on the created _Audit_ records with field data from the source _Proposed Audit_ records. For Vault to transfer data between the correct fields, you must [add fields](/en/lr/15057/#how-to-add-object-fields) to the _Proposed Audit_ object with an identical field _Name_ attribute value and field type as the fields on the _Audit_ object. For example, to transfer the _Executive Summary_ (`executive_summary__c`) field value, a field with an identical _Name_ attribute value (`executive_summary__c`) must exist on both objects.

Vault does not transfer data from standard fields (fields with a `__v` [namespace](/en/lr/22904/#namespace) suffix), with the exception of the following fields:

* _Facility_ (`facility__v`)
* _Title_ (`title__v`)

Ensure you activate the _Related Audit Program_ and _Related Proposed Audit_ fields on the required _Audit_ object types.

### Audit & Proposed Audit Object Types {#object-types}

If your processes include any [custom object types](/en/lr/32857/) 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 {#layouts}

We recommend updating [object layouts](/en/lr/26387/) 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 {#config-actions}

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 {#create-audit-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](/en/lr/59885/#entry-actions). 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 {#create-proposed-audits}

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](/en/lr/33946/) 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](/en/lr/43127/) to the _Audit Program_ object. When adding the action, do not select the _Available in All Lifecycle States_ checkbox.
4. [Add](/en/lr/59885/#user-actions) 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**.

### Configuring the Change Related Object Lifecycle State Action {#change-state-action}

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](/en/lr/59885/#entry-actions) 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](/en/lr/59885/#entry-actions) 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 {#workflows}

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 {#teams}

While you can create custom user fields to define roles, we recommend that you enable [_Teams_](/en/lr/70761/) 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 {#user-perm}

You must ensure users have the appropriate read and create [permissions](/en/lr/22824/) 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

## Related Permissions {#permissions}

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](/en/lr/22824/):

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

[1]: #configuring-objects
[2]: #layouts
[3]: #create-audit-action
[4]: #change-state-action
[5]: #workflows
[6]: #teams
[7]: #config-actions
[8]: #user-perm
[9]: #create-proposed-audits