# Configuring Audit Room

QMS provides an Audit Room management solution to facilitate the time-sensitive activity of conducting third-party audits. Team members participating in an audit can create requests from the front room, associate them with documents or attachments, and manage them in the back room. Vault allows them to communicate the priority, status, and fulfillment of each request, publishing them to inspectors when ready. The functionality is facilitated by the [Audit Room](/en/lr/780444/) application page, a collaborative drag-and-drop interface that assists organizations with responding to requests and efficiently presenting information to auditors.

Admins can only configure the Audit Room feature suite in systems with QMS enabled. This article outlines how to configure and integrate the feature with existing _Audit_ lifecycles.

<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>: The Audit Room does not rely on workflows to process <em>Inspection Requests</em> and instead utilizes a drag-and-drop interface to advance a request through its lifecycle. This approach is designed to optimize the experience of fulfilling <em>Inspection Requests</em> during the often high-intensity, active timelines while an audit or inspection is in progress. Introduction of workflows to <em>Inspection Request</em> records is possible, but generally not recommended, as they may add overhead or excessive notifications to users already engaged in the Audit Room. Keep this in mind when working with your business team to ensure a good process is defined.</p>
    </div>
  </div>
</div>



## Configuration Overview

<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>: The configuration information for Audit Room outlined below includes information on how to get started with sharing supporting records with auditors. Review this information to determine whether working with supporting records is right for your organization. If leveraging supporting records is not suitable for your organization at this time, you may continue fulfilling <em>Inspection Requests</em> using attachments or supporting documents.</p>
    </div>
  </div>
</div>



Configuring the Audit Room feature suite consists of the following configuration tasks: 

* Configuring supporting records for _Inspection Requests_.
* Configuring security and permission sets for the _Inspector_ role.
* Configuring atomic security and page layouts for the _Inspector_ role on all content that can be shared while publishing an _Inspection Request_.
* Configuring Audit Room for Inspectors.
* Configuring a Quality Team for inspections who can staff the _Front Office_, _Fulfiller_, and _Inspection Audit Room Owner_ members of _Audit_ and _Inspection_ records. 

Configuring the _Inspection Request_ needs to enable Inspectors to create _Inspection Requests_, fill out the request details simply, and track their progress on closing out requests in the _Published_ lifecycle state using the _Inspector Status_ picklist. We recommend hiding or locking all other fields and sections on an _Inspection Request_ to the _Inspector_ role via atomic security on the _Inspection Request_ object. Hiding or locking these fields and sections keeps things simple for Inspectors. For example, fields that may be considered internal, such as _Request Notes_, should be hidden from the _Inspector_ role for _Inspection Requests_ in a _Published_ state. Sections like _Related Object_ should not be viewable for _Inspection Requests_ in the _Published_ state. However, we do recommend that the Supporting Records section be viewable only in the _Published_ state.

Configuring the _Inspection Request_ also needs to enable members of the Fulfillment team (members with the _Front Office_ and _Fulfiller_ application roles, and, optionally, the _Inspection Audit Rooom Owner_ role) to attach supporting documents, records, or attachments, to capture response details and make notes about the request, and to allow members of the Fulfillment team to move the _Inspection Request_ between its lifecycle states either via optional user actions or the _Audit Room_.

Inspectors are granted _Inspector_ application role membership and associated permissions to shared records and documents as part of satisfying an _Inspection Request_. The lifecycles of any object or shareable document should have their respective _Inspector_ role permissions reviewed to ensure that any shared information is appropriate and clearly interpretable by an Inspector. [Layouts](/en/lr/26387/) and [layout profiles](/en/lr/582159/) are excellent tools for configuring a clear and focused experience in these areas.

To allow users to utilize the Audit Room feature suite, we recommend completing the following configuration steps in your Vault:

1. Ensure that at least one object type on the _Audit_ (`audit__qdm`) object is active.
2. In order to utilize Audit Room, update your permission sets under **Admin > Users & Groups > Permission Sets > [Permission Set] > Pages > Audit Room**.
3. Optional: Add more values to the _Category_ [picklist](/en/lr/1269/) for _Inspection Requests_, and enable attachments.
4. Optional: Configure the _Inspection Request_ object to allow fulfillers to attach [supporting records][7] to _Inspection Requests_.
   1. Add the _Related Object Reference_ section to the _Inspection Request_ object for each type of supporting record you want to share.
   2. To allow members of the Fulfillment team to share records for the supported objects, add the relevant _Inspection Request_-related object section to the _Inspection Request_ object page layout.
   3. To allow Inspectors to review materials attached and shared via the Fulfillment team, add the _Supporting Records_ app control to the _Inspection Request_ object page layout.
   4. Recommended: Configure the state visibility of each _Inspection Request_-related object section so that they only show in states other than _Published_.
   5. Recommended: Configure the state visibility of the Supporting Records app control section to only display _Inspection Requests_ in the _Published_ state. 
5. [Activate](/en/lr/618/#EnablingDocTypes) the _QMS Generated Document > Audit > Scribe Notes_ document classification and the corresponding _QMS Generated_ document lifecycle.
6. Ensure that the _Scribe Notes_ document reference field is enabled for the _Inspection_ object type or any object type with which you intend to use Audit Room and _Scribe Notes_. If you require more than one _Scribe Notes_ document, add an _Audit-Document_ related object section to the _Audit_ layout for _Inspections_.
7. Recommended: If you are using _Scribe Notes_, utilize [_Generate Document from Template_](/en/lr/72016/#doc-template-action) entry actions on the _Audit_ lifecycle to generate and populate the _Scribe Notes_ field in any noninitial lifecycle state before an Audit Room-enabled record is opened up for users to enter the Audit Room. If you require more than one _Scribe Note_, you can instead configure the _Generate Document from Template_ action on the _Audit-Document_ lifecycle.
8. Optional: To configure the _Inspection Request_ object, activate and configure atomic security for the _Inspector Status_ picklist field. 
9. Ensure that the _Inspector_ object type on the _Person_ object is active.
10. Configure the _Audit_ and _Inspection Request_ [page layouts](/en/lr/26387/) according to your business needs. Ensure that a _Related_ object section for _Inspection Requests_ exists on the _Audit_ object page layout.
    1. For audits and inspections, allow teams to see _Inspection Requests_ during Audit Room activities.
    2. For _Inspection Requests_, utilize atomic security on the _Published_ state to hide fields, such as the _Request Comments_ or _Response Comments_ field, that you do not want to share with an Inspector.
11. Add the _QMS Inspection_ (`qms__v`) tab collection to your navigation, and activate the [_Inspector Portal_](/en/lr/780443/#inspector-page) tab, inactivating other tabs in that collection. This tab ensures that Inspectors can access the portal when they're invited to provide and review requests.
12. [Add](/en/lr/36440/) the _Inspector_, _Fulfiller_, _Front Office_, and _Inspection Audit Room Owner_ application roles to the _Audit Lifecycle_ and _Inspection Request Lifecycle_ if not present.
13. Review and edit the atomic security for fields and relationships on the _Audit_ and _Inspection_ objects and the _Inspection Requests_ object for the _Inspector_, _Fulfiller_, _Inspection Audit Room Owner_, and _Front Office_ application roles on the [_Audit Lifecycle_][1] and [_Inspection Request Lifecycle_][2].
14. Configure [security for Inspectors][3] to access certain fields, documents, attachments, or [supporting records][7] when they access records in Vault.
    1. Inspectors will be granted _Inspector_ role membership to object records and documents shared directly with them as part of publishing an _Inspection Request_. Ensure that in all lifecycle states for all shareable types that the _Inspector_ role has appropriate _Read_-only permissions for the appropriate fields.
    2. Optional: Allow Inspectors to edit the _Inspector Status_ field of the _Inspection Request_ object in the _Published_ state of the lifecycle so that they can track their progress.
15. [Set up VeevaID][4] or [External User][5] licenses to accommodate Inspectors accessing Vault. We recommend that you implement only one of these approaches for all inspections within the same Vault.
16. Add the _Enter Audit Room_ object action to the _Audit_ object. This allows your Fulfillment team to enter the Audit Room. This action should not be made available to Inspectors or any users not intended to work with the Audit Room. 
    1.  Recommended: During configuration, leave the _Available in All Lifecycle States_ option unchecked so that you can instead leverage Action Security within the _Audit_ object lifecycle configuration covered in Step 12. 
    2.  Users who are invited to ad hoc fulfill _Inspection Requests_ via user tasks, workflows, or other similar mechanisms do not need access to the Audit Room and may provide such responses directly on the records themselves.
17. Add the _Enter Audit Room_ user action to the applicable state of the _Audit Lifecycle_. Optionally, review this state's _Atomic Security: Actions_ settings to further control relevant users' access to the _Enter Audit Room_ action.
18. Optional: Add entry criteria to the desired states on the _Inspection Request Lifecycle_ to check for field values before a record progresses. Vault still applies these criteria when users initiate state changes from within the Audit Room.
19. Optional: Configure the _Inspection Request_ lifecycle with state types and states applicable to your business processes, then [configure which states display to the fulfillment team in the Audit Room][8].
20. Configure a [_Quality Team_][6] for the _Inspection_ object type on the _Audit_ object. The team must specify the members of the [_Front Office_, _Inspection Audit Room Owner_, and _Fulfiller_ application roles](/en/lr/780443/). The team should not include a role for Inspectors. 
    1.  Recommended: The _Front Office_ and _Fulfiller_ roles should have at least one user to [trigger the inspection to begin its lifecycle](/en/lr/54508/#change-record-state).

## Configuring Supporting Records for Inspection Requests {#configuring-supporting-records}

_Inspection Requests_ can support the automatic sharing of supported object records as part of publishing an _Inspection Request_. Some prepwork is required to ensure that your Vault grants the right access to the right elements of each supported object's records to the right audiences. Ensure that the following areas are configured to utilize supporting records for _Inspection Requests_:

* The security profile and permission sets for your Inspectors. Regardless of how your _Inspector_ accounts are provisioned, the permission set granted to your Inspectors must have _View_ permissions assigned to each of the supported objects and to the standard join object between the _Inspection Request_ and the supported object. For example, if you want to share _Complaints_ with Inspectors through this feature, the Inspector's permission set must have _View_ permissions for the _Complaint_ (`complaint__v`) object and the _Inspection Request - Complaint_ (`inspection_request_complaint__v`) object.
* The page layout of the _Inspection Request_ record. The _Inspection Request_ page layout should be set up so that Inspectors are shown only the fields most relevant to them. This includes, but is not limited to, the _Category, Inspection, Inspector, Request, and Response_ fields.
* The _Inspector_ role's permissions for supported object records.

### Supported Objects for Inspection Request Supporting Records

Records for the following object types may be shared with Inspectors to fulfill _Inspection Requests_:

* _Adverse Event Reports_
* _Audits_
* _Annual Product Quality Reviews (APQRs)_
* _Quality Management Reviews (QMRs)_
* _Impact Assessments_
* _Investigations and Lab Investigations_
* _Materials_
* _Products_
* _Supplier Corrective Action Requests (SCARs)_
* _Supplier Change Notification (SCN) Impact Assessments_
* _Qualifications_
* _Quality Events_ and standalone _Events_

### Considerations for Sharing Supporting Records

The 25R1 release introduces the sharing of supporting records directly with Inspectors is an early preview of the intended set of record sharing functionality within Audit Room. We recognize that this business area–-direct invitation of Inspectors into your system of record--is a sensitive area where it is critical to get the experience right, and provide the right tools to ensure a comprehensive, controlled suite of tools. This early preview of the feature is not yet recommended for production use and will be subject to enhancement and changes with future releases, but we wanted to get these tools into your hands for Sandbox and Evaluation environments to begin collecting feedback on a wide scale, across different organization sizes and specialities.

#### Sharing Supporting Records

Sharing supporting records requires a significant level of configuration. Inspectors are granted permissions to shared records via membership to a lifecycle role. Configuring this setup requires this role to have atomic security and page layouts configured for every lifecycle state for any object with records that can be shared with Inspectors. This is a significant amount of configuration per object to ensure a hardened and controlled environment for Inspectors to access the content.

#### Using the Inspector Role

Inspectors are granted permissions to shared records via membership specifically to the _Inspector_ (`inspector__v`) role of the lifecycle of the shared record. This lifecycle role may already be in use by your organization. The impact of adding Inspectors to that role should be considered to ensure that Inspectors are not invited to see information not intended for them.

#### Accessing Record Field Data Only

When a record is shared with an Inspector, only the field values on that record that are not hidden by permission set configurations or atomic security will be shared. For example, sharing a _Complaint_ will share all record field values, like _Description, Owning Department, Reported Date_, and so on. With 25R1, Vault will not be able to share with the Inspector-related records like _Root Cause Analyses_ or _Extension Requests._ A future release is planned to address visibility for inbound-related records.

## Permissions for the Audit Lifecycle {#permissions-audit-lifecycle}

Admins must [edit the role permissions](/en/lr/36440/) on the _Audit Lifecycle_ for each applicable application role. The _Front Office_ and _Fullfiller_ roles require _Edit_ permissions in the lifecycle states in which they can edit an _Inspection_ record. The _Inspector_ role only requires _View_ access to the _Audit_ object when it's in the _In Audit_ state. The permissions you grant the _Inspection Audit Room Owner_ role depend on your business needs, but may be similar to the _Front Office_ role.

## Permissions for the Inspection Request Lifecycle {#permissions-inspection-request-lifecycle}

Admins must [edit the role permissions](/en/lr/36440/) on the _Inspection Request Lifecycle_ for each applicable application role; at a minimum, this includes the _Front Office_, _Fulfiller_, and _Inspector_ roles, and, optionally, the _Inspection Audit Room Owner_ role. 

Admins must enable the Audit Room page for all permission sets for any user who intends to work with the Audit Room feature. At minimum, this includes any user who may be assigned as a _Front Office_ or _Fulfiller_ member of an audit or inspection. Vault displays an error message if the minimum permissions are not assigned at the object or field level to a user who attempts to access the Audit Room page.

The _Front Office_ and _Fulfiller_ roles require _Edit_ permissions in the lifecycle states in which they can edit an _Inspection Request_ record. We recommend granting _View_ permissions to these roles when requests are in the _Published_, _Closed_, or _Cancelled_ states, so that no data can change while it is actively being presented to an Inspector or after a closure or cancellation. The _Inspector_ role only requires _View_ access to the _Inspection Request_ object when it's in the _Published_ state.

The standard _Inspector_ (`inspection_inspector__v`) permission set provides an example to use with Audit Room, if you want to enable sharing of all supported objects and documents with an Inspector. You can copy this permission set to get started. If your organization chooses to enable sharing documents or records with Inspectors directly as part of an _Inspection Request_, for each type of entity that can be shared, the Inspector's permission set must have, at minimum, _View_ permissions for the object or document being shared, the join object linking that entity, and the _Inspection Request_. For example, if you want to share documents and _Complaints_ with Inspectors, the _Inspector_ permission set must have at least _View_ permissions for the _Inspection Request_ object, the _Inspection Request - Document_ object, the _Documents_ object, the _Inspection Request - Complaints_ object, and the _Complaint_ object. For each shared object, _View_ permissions are required for all types which may be shared with an Inspector.

<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>: Inspectors do not require permission set access to objects that may be rendered as field values, such as outbound references, from shared documents or objects. For example, if a <em>Complaint</em> has a <em>Country of Origin</em> field that points to a single <em>Country</em> object, the Inspector can see the name of the <em>Country of Origin</em> field’s selected value even without any permission set access to the <em>Country</em> object. Unless you grant that Inspector permissions to the <em>Country</em> object’s records via some other mechanism, they cannot view the record details page for that value’s record.</p>
    </div>
  </div>
</div>



## Permissions for Sharing Supported Records

Admins must configure the Inspector security profile with a permission set that provides _View_ permissions to all of the supported objects. Once a supporting record is added to an _Inspection Request_, the Supporting Records feature utilizes the _Inspector_ role for the Inspector on the related object to grant the Inspector _View_ access to that single record. We recommend configuring a [layout](/en/lr/26387/) and [layout profile](/en/lr/582159/) for the _Inspector_ role to ensure that the presentation matches your organization's needs.

## Permissions for Automatic Assignment for Inspection Requests

Admins must [edit the role permissions](/en/lr/36440/) on the _Inspection Request Auto Assignment_ object for each applicable application role. To define the alignment of fulfillers to their automatic assignments, we recommend granting the _Front Office_, _Fulfiller_, and, optionally, the _Inspection Audit Room Owner_ roles _Read_ and _Edit_ permissions on the _Inspection Request Auto Assignment_ object. This ensures that these users can add the appropriate _Request Category_ to _Inspection Request Auto Assignment_ records.

## Configuring the Audit Room Page {#audit-room-page}

Users assigned to the _Inspection Audit Room Owner_ role on an _Inspection_ can configure custom and standard states on the _Inspection Request Lifecycle_ to display in the Audit Room, and update their display order. Only states associated with a state type are available to display.

To configure states to display in the Audit Room:

1. Configure the _Inspection Request Lifecycle_ to suit your business processes in the following ways:
    * [Create](/en/lr/30683/#define-states) custom states to display in the Audit Room, and associate them with a custom or standard state type.
    * [Create](/en/lr/56431/#how-to-create-object-state-types) custom state types and [associate](/en/lr/30683/#associate-state-type) them with a state in the _Inspection Request Lifecycle_.
    * Relabel standard states and state types. 
    * [Modify](/en/lr/30683/#associate-state-type) the states that standard and custom state types are associated with, excluding the _Initiated_ and _Published_ states.
2. From the Audit Room, open the **Audit Room Owner Actions** menu and select **Configure State Lanes**.
3. From the _State Lanes_ dialog, move states from the _Available States_ column to the _Selected States_ to display them in the Audit Room, or remove them from _Selected States_ to remove them from the Audit Room. The _Initiated_, and _Published_ states cannot be removed. You can select up to ten states to display.
4. When you are finished, click **Save**.

## Configuring the Inspection Page {#configuring-inspection-page}

Admins can configure the _Inspection_ application page through its configuration page. This allows you to determine what is displayed to Inspectors. _Title_, _Purpose_, and _Scope_ are displayed by default, but you also can configure _Date_ and _Text_ fields and picklists. Up to three _Summary_ fields also may be added.

You also should configure the _Audit_ and _Inspection Request_ page layouts according to your business needs. We recommend adding the necessary fields to the list layout for when Inspectors are viewing their assigned _Inspection Requests_ from the _Inspections_ tab or the _Inspection_ application page. Additionally, ensure that a _Related Objects_ section for _Inspection Requests_ is added to the _Audit_ object page layout.

## Setting Up VeevaID for Inspectors {#setting-up-veevaid}

We recommend configuring the Audit Room feature with [VeevaID](/en/lr/23050/) to invite Inspectors to a limited version of Vault. Complete the following configuration steps to ensure that Inspectors receive automated invites to register for VeevaID and can view the appropriate pages:

  1. Ensure the standard _QMS_ (`qms__v`) tab is active.
  2. Add the _Persons_-related object section to the _Inspection_ object type page layout. This section is where Inspectors will be created and selected for an inspection.
  3. Add the _Invite Inspectors to VeevaID_ user action to an appropriate lifecycle state of the _Inspection Lifecycle_. You can also configure this as an entry action.
  4. Ensure that Inspectors are granted _Inspector_ role membership to object records and documents shared directly with them as part of publishing an _Inspection Request_. Ensure that in all lifecycle states for all shareable types that the _Inspector_ role has appropriate _Read_-only permissions for the appropriate fields.
  5. Ensure that the permission set granted to your Inspectors has _View_ permissions assigned to each of the supported objects and to the standard join object between the _Inspection Request_ and the supported object.

## Setting Up External Users for Inspectors {#setting-up-external-users}

As an alternative to setting up VeevaID, you can configure External Users to give Inspectors access to Vault. For organizations who prefer to directly create, manage, and maintain External User accounts and licenses for their Inspectors, complete the following steps in your Vault:

  1. Ensure the standard _QMS_ (`qms__v`) tab is active.
  2. Ensure that Inspectors are granted _Inspector_ role membership to object records and documents shared directly with them as part of publishing an _Inspection Request_. Ensure that in all lifecycle states for all shareable types that the _Inspector_ role has appropriate _Read_-only permissions for the appropriate fields.
  3. Ensure that the permission set granted to your Inspectors has _View_ permissions assigned to each of the supported objects and to the standard join object between the _Inspection Request_ and the supported object.
  4. Add the _Persons_-related object section to the _Inspection_ object type page layout.
  5. Create a Vault user automatically via [external collaboration](/en/lr/65816/) or manually via an _External License_, and assign the _Inspector_ application role to the new user.
  6. If you are creating a user manually, create a _Person_ record and link it to the _User_ record created above.

## Configuring a Quality Team for Inspections {#configuring-quality-team}

You can create a [_Quality Team_](/en/lr/54508/) for the _Inspection_ object type on the _Audit_ object to facilitate the assignment of team members to specific sharing settings on an _Inspection_ object record. Create team roles to link to the _Front Office_, _Fulfiller_, and _Inspection Audit Room Owner_ application roles. You can define role membership restrictions if suitable for your organization's needs. We also recommend securing the _Inspection Request_ related object for each team role created in the _Quality Team_ definition. When assigning teams, we recommend that the user, such as an Audit Lead, who is assigned to the _Front Office_ role also be assigned to the _Inspection Audit Room Owner_ role.

### Related Permissions

To view the team members section on a record, a user requires _Read_ permission on the relevant team-enabled object. To add, remove, or otherwise manage _Quality Team_ members, a user requires _Edit_ permission on the relevant team-enabled object. The ability to edit _Quality Teams_ on team-enabled objects in a given lifecycle state also depends on the lifecycle's [Atomic Security on Relationships](/en/lr/47850/) or [locked state](/en/lr/54508/#locked-states) configuration.

## Configuring Nudge and Group Nudge Notifications

Users with access to the Audit Room can send a notification to nudge _Assignees_ or groups of Vault users about _Inspection Requests_ that require their attention. The Nudges utilize notification templates to send messages via email for more efficient communication during inspections and audits. Nudges and Group Nudges are available on the Audit Room application page through the _Inspection Request_ card or the _Send Nudge Notification_ user action.

Complete the following configuration steps to utilize Nudge and Group Nudge notifications:

1. Optional: Nudges and Group Nudges are auto-on in the Audit Room and do not require configuration. However, you can optionally configure the _Send Nudge Notification_ user action on the _Inspection Request_ object lifecycle to allow users to perform a Nudge from a record detail page if desired.
2. Configure the Nudge [notification templates](/en/lr/77672/#notification-templates). You can use the following default templates or customize them to suit your business needs:
   1. _Inspection Request Assignment_ (`inspection_request_assignment__v`)
   2. _Inspection Request – Group Assignment_ (`inspection_group_assignment__v`)
   3. _Inspection Notice – Attention Required_ (`inspection_notice__v`)
   4. _URGENT – High Priority Request_ (`urgent_inspection_request__v`)
   5. _Action Required – Audit Room Participation_ (`audit_room_participation__v`)
3. Configure the _Inspection Group Fulfiller_ (`inspection_group_fulfiller__v`) application role. This role is utilized to automatically add users who are not members of the Fulfillment team but who have group tasks related to the inspection to the _Inspection Request_ record. We recommend granting this role similar permissions that members of the _Fulfiller_ role have on _Inspection Requests_.
4. Optional: Update the _Inspection Request_ page layout to direct members of the _Inspection Group Fulfiller_ role to populate the _Assignee_ field to claim an _Inspection Request_ as their own.

### Related Permissions

Ensure that users in the _Inspection Group Fulfiller_ role have _Read_ and _Edit_ permission on the _Inspection Request_ object.

[1]: #permissions-audit-lifecycle
[2]: #permissions-inspection-request-lifecycle
[3]: #configuring-security-inspectors
[4]: #setting-up-veevaid
[5]: #setting-up-external-users
[6]: #configuring-quality-team
[7]: #configuring-supporting-records
[8]: #audit-room-page