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

Configuration Overview

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 and Fulfiller 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) 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 Viewer application role membership and associated permissions to records shared as part of satisfying an Inspection Request. Inspectors also are granted Inspector application role membership and associated permissions to documents. The lifecycles of any object or shareable document should have their respective Viewer role or Inspector role permissions reviewed to ensure that any shared information is appropriate and clearly interpretable by an Inspector. Layouts and layout profiles 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 for Inspection Requests, and enable attachments.
4. Optional: Configure the Inspection Request object to allow fulfillers to attach supporting records 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. 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.
6. Recommended: If you are using Scribe Notes, utilize Generate Document from Template entry actions on the Inspection Request 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.
7. Optional: To configure the Inspection Request object, activate and configure atomic security for the Inspector Status picklist field. 
8. Ensure that the Inspector object type on the Person object is active.
9. Configure the Audit and Inspection Request page layouts 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.
10. Add the QMS Inspection (qms__v) tab collection to your navigation, and activate the Inspector Portal 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.
11. Add the Inspector, Fulfiller, and Front Office application roles to the Audit Lifecycle and Inspection Request Lifecycle if not present.
12. 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, and Front Office application roles on the Audit Lifecycle and Inspection Request Lifecycle.
13. Configure security for Inspectors to access certain fields, documents, attachments, or supporting records when they access records in Vault.
    1. Inspectors will be granted Viewer role membership to object records and Inspector role membership to documents shared directly with them as part of publishing an Inspection Request. Ensure that in all lifecycle states for all shareable types that the Viewer and Inspector roles have 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.
14. Set up VeevaID or External User licenses to accommodate Inspectors accessing Vault. We recommend that you implement only one of these approaches for all inspections within the same Vault.
15. 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.
16. 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.
17. 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.
18. Configure a Quality Team for the Inspection object type on the Audit object. The team must specify the members of the Front Office and Fulfiller application roles. The team should not include a role for Inspectors. 
    1. Recommended: The Front Office and Fulfiller roles should have at least one (1) user to trigger the inspection to begin its lifecycle.

Configuring Supporting Records for Inspection Requests

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. Visibility to supported object records is granted through automatically managed membership to the Viewer role on the shared record’s lifecycle. 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 Viewer 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 Viewer Role

In 25R1, Inspectors are granted permissions to shared records via membership specifically to the Viewer (viewer__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. Before implementing and using this feature, we recommend reviewing possible configurations, which include, but are not limited to, uses like: 

• Notifications on entry actions that send to all roles or the Viewer role.
• Process notifications like Issue Escalation that are sent to the Viewer role.
• If the Viewer role is used for tasks in any configuration.
• If the Viewer role is used for reports in any configuration, such as flash reports.

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.

Future Updates for the Viewer Role

The 25R1 release ties all Inspector visibility to membership of any shared record’s Viewer (viewer__v) role. To utilize sharing supporting records with Inspectors, your configuration must address atomic security and layouts for that role in every state of a shareable object record’s lifecycle. In future releases, we will not be continuing with this role. Ensure that your configurations are applied so that you can also utilize the upcoming functionality. We do not plan to migrate the configurations from the Viewer role to the upcoming data model.

Permissions for the Audit Lifecycle

Admins must edit the role permissions 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.

Permissions for the Inspection Request Lifecycle

Admins must edit the role permissions on the Inspection Request Lifecycle for each applicable application role; at a minimum, this includes the Front Office, Fulfiller, and Inspector roles. 

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.

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 Viewer role for the Inspector on the related object to grant the Inspector View access to that single record. We recommend configuring a layout and layout profile for the Viewer role to ensure that the presentation matches your organization’s needs.

Permissions for Automatic Assignment for Inspection Requests

Admins must edit the role permissions 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 and Fulfiller 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 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 (3) 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

We recommend configuring the Audit Room feature with VeevaID 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 Viewer role membership to object records and Inspector role membership to documents shared directly with them as part of publishing an Inspection Request. Ensure that in all lifecycle states for all shareable types that the Viewer and Inspector roles have 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

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 Viewer role membership to object records and Inspector role membership to documents shared directly with them as part of publishing an Inspection Request. Ensure that in all lifecycle states for all shareable types that the Viewer and Inspector roles have 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 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

You can create a Quality Team 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 at least two (2) team roles to link to the Front Office and Fulfiller 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.

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 or locked state configuration.