# Configuring Quality Teams (QMS)

Admins can create and configure [_Quality Teams_](/en/lr/52842/) and _Quality Team Roles_ to suit their needs. For example, a _Change Control_ might require three team roles to work through from start to finish: a "Change Owner", a "Lead QA Engineer" and "Subject Matter Experts". Using _Quality Teams_ allows you to dictate that every created _Change Control_ requires exactly one "Change Owner", exactly one "Lead QA Engineer" and between zero and five "Subject Matter Experts" in order to begin work.

_Quality Teams_ allow users to make individual work assignments to individual _Change Controls_, _Audits_, _CAPAs_, or other _Quality Event_-related processes. Users define these [assignments](/en/lr/52842/#assigning-users) directly from the record detail page by selecting individual user assignments from a list of users authorized to perform that role on that record. _Quality Teams_ integrates with object record [sharing settings](/en/lr/25494/), allowing for a simple experience without sacrificing critical compliance tools.

## How Quality Teams Work

You can create a _Quality Team_ for any non-system object, with some [limitations][1], that does not already have a _Quality Team_ configured. In objects which have object types, you can configure a _Quality Team_ for either:

  * A single object type; or
  * All object types which do not have a specific _Quality Team_ definition

When defining _Quality Teams_, you can configure options such as lifecycle state changes that can trigger automated events. You can also lock the membership of all team roles in selected lifecycle states. For example, you might define a procedure dictating that all _Change Controls_ are created in a "Pending Team Assignment" state that has no associated workflows. You can then configure Vault to automatically move the _Change Control_ into the _Initiated_ state of its lifecycle once the "Change Owner" and "Lead QA" have both been selected. The team completion can even start a workflow, assigning tasks to the team members defined.

## Creating Quality Teams

### How to Create a Quality Team Definition

  1. Navigate to **Admin** > **Configuration** > **Quality Teams**.
  2. Click **Create**.
  3. Enter a **Label** and **Name**.
  4. Select a **Status**. If you set a team to _Inactive_, Vault retains the team and role configuration, but the team won't appear on associated object records. If you reactivate the team later, or create a new team for the same object and role, Vault preserves any team member assignments. This option can be helpful during initial configuration or in the event that you no longer want to use this team.
  5. Select an **Object** that this _Quality Team_ applies to. If the object has types, you can select an **Object Type**. Once you create a _Quality Team_, you cannot change this option. You can have only one _Quality Team_ active per object or type (if the object is typed).
  6. Optional: Select the **Change record state when team is complete** checkbox. See [details][5].
  7. Optional: Select one or more **Locked States**. See [details][4].
  7. Click **Save**. Vault takes you to the newly-created _Quality Team_ definition page.

Once you create the _Quality Team_, Vault updates the relevant object page layouts with a _Quality Team Members_ section. This page layout section shows team assignments and allows authorized users to select users for roles. We recommend editing your object page layout to make this section the first or second section on the page.

If associated object records exist before you configure a team and team roles, they will have _Quality Team_ sections without assigned members after you configure the team.

Note that you cannot edit the _Quality Team_ definition while creating or reordering _Quality Team Roles_.

### Change Record State when Team is Complete {#change-record-state}

Select this checkbox, a **Start State**, and a **Destination State** to move an object record to a new state upon completion of the minimum _Quality Team_ membership. This state change will also trigger any associated automated events, such as auto-starting workflows. Vault completes this event for an object record when:

  * The team has at least one team role which with a _Minimum Required Users_ of at least one (1);
  * All roles which have the _Minimum Required Users_ defined have that number of assignments; and
  * A user updates the team members and the record is in the defined _Start State_

### Locked States {#locked-states}

When the associated object record is in one of these specified locked lifecycle states, no user in the Vault may make changes to the membership of this _Quality Team_, including Vault Owners. Additionally, team-enabled records in _Locked States_ will not raise alerts for invalid or incomplete team assignments. This option is intended for end-of-life states of records' lifecycles, where assignment information must be retained.

### Quality Team Member Hovercards

Once you define your _Quality Team_ and create [_Team Roles_][9], you can hover on a team member's name to view a hovercard. To configure which fields are shown in the hovercard, navigate to **Admin > Object > User > Fields > \[Field\]** and select or clear the **Display in default lists and hovercard**s checkbox. Vault only displays a _User_ object field in the hovercard if the checkbox is selected.

### How to Delete Quality Teams

You cannot delete a _Quality Team_ definition if any record which uses that team has any team member assignments. To delete a _Quality Team_ definition, you must first remove all _Quality Team_ members on all records which use it. To simplify this process, an Admin can use the [Power Delete Quality Team Members][2] record action, or [make it available on the appropriate team enabled object](/en/lr/43127/).

## Creating Quality Team Roles {#create-team-roles}

After defining your _Quality Team_, you can also create _Team Roles_. Vault associates team roles directly with _Application Roles_, and you can configure these with several options.

<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>: Your Vault may be configured to use the <em>Quality Event</em> object, or individual objects to represent quality events, such as <em>Complaints</em> and <em>Deviations</em>. Ensure that you are aware of which objects your Vault configuration utilizes before attempting to configure <em>Quality Teams</em> for your core process objects.</p>
    </div>
  </div>
</div>



### How to Create a Quality Team Role

  1. Navigate to **Admin > Configuration > Quality Teams** and select the _Quality Team_ for which you wish to create roles.
  2. In the _Team Roles_ panel, click **Create**.
  3. Enter a **Label** and **Name**.
  4. Select a **Status**.
  5. Select an **Application Role**. _Quality Team_ members with this team role are added to the selected _Application Role_ on the object record. You cannot change this once you save the _Team Role_. See the [limitations][1] for _Application Roles_ that can be assigned to a _Quality Team Role_.
  6. Optional: Enter **Help Content**. This will appear to all users who hover over the role label in the _Quality Team_ section of the associated object record detail page. You can use this text to provide clarity around who you can or should select for a role.
  7. Optional: Select the **Minimum Required Users** for this role. If you do not select a number, or if you select a minimum of zero (0), this role is optional, and the _Quality Team_ membership may be completed with this role unassigned. To make a role's membership conditionally optional based on business logic, you can select a minimum of zero (0), then leverage the relevant entry criteria configuration options.
  8. Select the **Maximum Users** that can be assigned to this role.
  9. Optional: Select the **Exclusive Membership?** checkbox to make the role's membership exclusive. A team member in an exclusive role may not be a member of any other role on the same team for a given object record. You can configure further limits on role exclusivity using [role membership restrictions][8].
  10. Optional: In the **Linked Field** drop-down, select a _User_ object reference field on the team-enabled object. The value of the selected field is linked to the _User_ assigned in this _Quality Team Role_ on records of that object. This option can only be used if this role definition has a _Maximum Users_ value of one (1). See [details][5] about linked _User_ fields.
  11. Optional: Select a **Constraining Application Role** to allow Vault to populate the _Quality Team_ assignment options with only users in the selected role. Note that to prevent a role from becoming unfillable, you cannot constrain an _Application Role_ by itself. Constraining roles may be populated by matching or custom sharing rules.
  12. Optional: In the _Inherit Behavior_ field, select **Inherit** to allow this role to check the value of the configured _Inherit From_ field on this role. See details about [Inherit Behavior][3] below.
  13. Optional: Select a role to **Inherit From**. This field is required if you selected the _Inherit Behavior_. This field identifies how this team role finds a record to [inherit its membership][3] from.
  14. Optional: If you selected the _Inherit from Quality Event_ option in the _Inherit Behavior_ field, then in the **Inherit From Quality Events** field, select one or more [objects][3]. Team-enabled objects for which there is an outbound reference field on this _Quality Team_'s object are available for selection. Records can only inherit their team role memberships from a single record at a given time, thus this function is only supported for records which only have one of the selected fields populated. Use this function for sub-processes which are commonly shared across various types of events, such as _Effectiveness Checks_ or _Extension Requests_, in Vault configurations using standalone objects for their types of events, such as _Deviations_ or _Complaints_.
  15. Optional: Select **Locked States**. While an object record is in a defined _Locked State_, no Vault user can edit or change this role's membership, including Vault Owners. Role membership exclusivity for _Team Roles_ in a _Locked State_ may not be taken into account when updating _Team Role_ assignments.
  16. Click **Save**. Vault creates the _Team Role_ and associates it with its parent _Quality Team_.

The new role appears in the list at the bottom of the _Quality Team_ definition page. Vault immediately adds the role to all existing records for the associated object.

Note that if users can change membership while a _Quality Team Role_'s workflow tasks are active, Admins should design the workflow to handle a lack of verdict due to task cancelation.

## About Inherit Behavior {#about-inherit-behavior}

_Team Role_ memberships can be inherited from other parent processes if the _Inherit Behavior_ attribute is populated. Inheritance will populate a _Team Role's_ membership in these cases:

* Upon record creation
* When a user clicks **Restore** for a given role while managing a team
* When a user changes the _Team Role_ membership on the record that this record is configured to inherit from (and inheritance is not [broken](/en/lr/52842/#restoring-inherited-team-members))

Inheritance behavior can be configured in one of three ways:

* **Blank**: The _Team Role_ membership of the _Quality Team_ is independent from the _Team Role_ memberships of other records.
* **Inherit**: The _Team Role_ membership of the _Quality Team_ by default is derived from and governed by the _Team Role_ membership of another role on a record of the selected parent object (as specified in the _Inherit From_ attribute of the _Team Role_).
* **Inherit from Quality Events**: The _Team Role_ membership of the _Quality Team_ by default is derived from and governed by the _Team Role_ membership of another role on a record of one of the selected objects (specified in the _Inherit from Quality Events_ attribute of the _Team Role_).
  *  This option is primarily for customers who have migrated from the merged _Quality Event_ data model to the standalone _Quality Event_ data model and is available in the configuration of _Quality Teams_ for a subset of [objects][10] available in the Vault.

Once an object with a _Quality Team_ definition is selected to inherit from, this _Team Role_ will inherit the membership from that record's Team Role (matched based on having the same _Application Role_ configuration). In practice, even when a record is configured to inherit the team assignments from another process, inheritance may not occur if there is no valid assignment to inherit. Scenarios where this may occur include: 

* If no parent record exists to inherit from
* If the parent record has no team members defined
* If the parent record's currently assigned team is [invalid](/en/lr/52842/#invalid-team-members)
* If the record's team has no role linked to the _Team Role_'s _Application Role_

The following behaviors apply with role inheriting enabled:

* Users can still manually edit a _Team Role_'s membership. Doing so will cause the role to no longer inherit membership changes from a parent _Team Role_ membership until the **Restore** operation is executed on the _Team Role_.
* The **Restore** option is available for users managing the team.
* Changes to the linked object record's _Team Role_ membership cascade down to the record's _Team Role_ unless membership of this role has been manually changed.


<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>: <a href="/en/lr/47850/">Atomic Security on Relationships</a>, or an inheriting processes’ <em>Quality Team Role</em> constraining roles may interfere with inheriting role behaviors. We recommend using <em>Locked States</em> as an alternative to Atomic Security on Relationships, and aligning your constraining roles’ population rules to avoid this. You can safely use Atomic Security on Relationships to prevent any non-team-member from changing the membership of any team role.</p>
    </div>
  </div>
</div>



### Supported Objects {#inherit-behavior-supported-objects}

Vault supports _Inherit Behavior: Inherit_ configurations for all objects which can have _Quality Teams_ enabled for them in the Vault.

Vault supports the _Inherit Behavior: Inherit from Quality Events_ for _Team Roles_ that are part of _Quality Teams_ for the following objects:

* _CAPA Action_
* _Change Action_
* _Effectiveness Check_
* _Extension Request_
* _Impact Assessment_
* _Investigation_
* _Issue Escalation_
* _Root Cause_
* _Root Cause Analysis_
* _SCAR_ 

Vault supports the following standard objects as valid objects to inherit _Team Role_ memberships from in the _Inherit from Quality Events_ attribute of a _Quality Team Role_ definition:

* _Change Control_
* _Change Plan_
* _Complaint_
* _Continuous Improvement_
* _Deviation_
* _Finding_
* _Lab Investigation_
* _Nonconformance_
* _MedTech CAPA_
* _Quality Event_

### How to Reorder Quality Team Roles

If you have created more than one role for the _Quality Team_, their order on the _Quality Team_ definition page matches the order of roles in the _Quality Team_ section on the associated object records.

To rearrange roles, click **Reorder**. Then, click and drag the roles by their shaded top left corner. Click **Save** to save your changed, or **Cancel** to exit without changing the order. Note that you cannot create or reorder roles while editing the _Quality Team_ definition.

## Linked Role Fields {#linked-fields}

Using the _Linked Field_ option in a team role definition can allow _Quality Team Role_ assignments to appear in related lists, searches, filters on library views, reports, and elsewhere in Vault that a _User_ object reference field may be accessible. Once linked to a team role, users or mechanisms may not update a given object reference field, other than via edits to the linked _Quality Team Role_. See the [limitations][7] for this option before deciding to implement it in your Vault.

When you change the linked team role's membership on a given team-enabled object record, Vault updates the record's linked field to reflect the new team role membership. The field update is asynchronous; if you change the team on a record, the linked field is updated soon after, but not instantly.

### Enabling Linked Role Fields for Quality Teams

To enable linked user field functionality:

  1. Create an object reference field, referencing the _User_ object, on the team-enabled object. If that object supports types, be sure to associate the field to the same type of object that your team is defined for.
  2. Add the field in the _Linked Field_ drop-down of the team role definition.

Because this field's functionality may not be apparent to users viewing the team-enabled object record, we recommend the following:

  * Do not add the linked role field to the team-enabled object page layout, or configure security to prevent users from trying to manually edit the linked field. Once linked to a role, Vault will prohibit edits to the field value, and there's no need to present fields as editable to your users if they're not actually editable.
  * Select the _Display on default lists and hovercards_ object field configuration setting to expose the team role in hovercards throughout Vault.
  * Define _Help Content_ for the linked field so that users know they can't manipulate the _Quality Team_ assignments by changing the field's value.

### Adding Linked Role Fields for Existing Team Role Assignments

Once enabled for objects that already have records with role assignments, Admins may choose an update strategy to update existing records' fields to match their pre-existing assignments' values. When updating existing records, affected records may have their linked field's values changed and Vault updates their modified-date and modified-by information accordingly.

This step is optional. If your organization chooses to keep pre-existing records untouched, you may skip this step. If you wish to update pre-existing records, Vault provides the following methods:

  * To blanket update all records which use a given team, click the **Sync linked role fields** button on the _Quality Team_ definition. This button appears once you select a _Linked Field_ in one of the team's role definitions. The button starts an asynchronous process to update records with the affected team assignments, linking their values. Vault sends you a notification email including the results of the process in a log file.
  * To more precisely update individual or a subset of records using a given team, a similar action is also available as a standard [record action](/en/lr/45776/): `Sync Linked Role Fields`, to be enabled and run on desired team-enabled record. You might use this record action if there are applicable team-enabled records that you do not want to update. For example, if they are already closed or locked.

#### Sync Linked Role Fields Job Log {#job-log}

The _Sync linked role fields_ process provides a job log, which lists the following information:

  * Each team-enabled record that had an assignment
  * Whether or not Vault successfully updated the team-enabled record
  * Errors encountered

The job skips any records that it cannot update. For example, suppose a role definition had a _Maximum Users_ value of more than one (1), then an Admin changed that _Maximum Users_ value to one (1) prior to adding a value to _Linked Field_. If there were existing records with teams that have more than one (1) assignment in that role, then the job would not be able to sync the linked role fields for those assignments or records and would log that error in the resulting [job log][6].

#### Limitations for Linked Role Fields {#lim-linked-role-fields}

The following limitations apply to linked role fields:

  * The _Maximum Users_ value in the _Quality Team Role_ definition must not be more than one (1).
  * A team role can only be linked to a single field.
  * While a single linked role field can be linked to several teams, only one role on a given team can be linked to the same field.

## About Locked States {#about-locked-states}

Both _Quality Team_ definitions and _Team Role_ definitions include options for selecting _Locked States_. These states prohibit change to the respective _Quality Team_ or _Team Role_ membership assignments, even by Vault Owners. These options are intended for record end-of-life states, where assignment information must be retained. Role membership exclusivity for _Team Roles_ in _Locked States_ may not be taken into account when updating _Team Role_ assignments.

## Creating Role Membership Restrictions {#role-membership-restrictions}

After defining _Team Roles_ for a _Quality Team_, you can also create _Role Membership Restrictions_. In contrast with the **Exclusive Membership?** checkbox available on a _Team Role_ record, using _Role Membership Restrictions_ allows for team role assignments to be limited among specific existing roles within a _Quality Team_. A _Quality Team_ must have a minimum of two active _Team Roles_ defined for this section to appear.

### How to Create a Role Membership Restriction

To create role membership restrictions:
1. Navigate to **Admin > Configuration > Quality Teams** and select the _Quality Team_.
2. Click **Edit**.
3. In the _Role Membership Restrictions_ panel, click **Add Restriction**. This button only appears if at least two active _Team Roles_ exist which do not have **Exclusive Membership?** enabled.
4. Select a **Role**. If a _Team Role_ has **Exclusive Membership?** enabled, it will appear in the list of roles but you cannot select it.
5. Select a value for **Is Exclusive With**. You cannot assign a team member in the role indicated in the **Role** field to the role indicated in this field.
6. Select a **Status**. If the status is set to _Inactive_, Vault does not apply the defined behavior to existing records for the associated object.
7. Click **Save**. Vault automatically creates an [inverse relationship](/en/lr/70474/) between the indicated roles. A team member in the role specified in the **Is Exclusive With** field will be unable to be assigned as a member of the **Role** field within the same _Quality Team_.

The new _Role Membership Restriction_ appears in the list at the bottom of the _Quality Team_ definition page. Vault automatically applies the restriction to all existing records for the associated object. Editing the _Quality Team_ record will allow for the creation of new restrictions, and edit or delete existing restrictions.

## Securing Related Objects<a id="securing-related-objects"></a>

A _Quality Team_ is used to manually assign users to roles for a specific process record, which may have relationships to other object records that are not team-enabled. By default, only the user who created those records can edit or delete them. The _Related Objects to Secure_ option within a _Quality Team_ definition can allow more flexible edit access to non-team-enabled records in cases where users are removed from a _Quality Team_ for the main record.

For example, in a _Deviation_ record, the Owner adds a related _Batch_ record to the _Deviation - Batch_ section and then, while the deviation is still in revision, the Owner leaves the organization. Any newly-assigned Owner will be unable to edit or delete, as they would lack the necessary sharing settings roles on the _Deviation-Batch_ record.

While assigning users to roles through a _Related Objects to Secure_ definition can provide edit and delete access for specific records, you must grant users the relevant object-level permissions for the related object. If the related object uses [Dynamic Access Control](/en/lr/33946/), you must also grant view access for the relevant records through [matching sharing rules](/en/lr/36122/) or [custom sharing rules](/en/lr/25494/).

To view roles assigned through a _Related Objects to Secure_ definition within the _Sharing Settings_ section on related object records, filter the _Sharing Settings_ section by [user](/en/lr/61279/#filter-by-user) and [role](/en/lr/61279/#filter-by-role). In most cases, roles assigned through related object security display with a checkmark in the _Application Override_ column.

### Defining Related Objects to Secure

To define related objects to secure on a _Quality Team_ definition:

  1. Navigate to **Admin > Configuration > Quality Teams** and click into a _Quality Team_ definition.
  2. Click **Edit**.
  3. In the _Related Objects to Secure_ section, click **+ Add Object**.
  4. Select the **Related Object** for which to define the security mapping.
  5. Select the **Outbound Reference Field** from the related object which references the team-enabled object.
  6. Select the **Quality Team Role** on the team-enabled object which defines the mapping.
  7. Select the **Application Role** which defines the access that the _Quality Team Role_ should possess.
  8. Select a **Status**, either _Active_ or _Inactive_. Inactive mappings will not provide any access to the related record.

You can repeat these steps to add more mappings to _Quality Team Roles_.

For example, on a _Deviation_ record, the following _Related Objects to Secure_ definition would provide the _Owner_ team member with an _Owner_ role in the sharing settings of any related _Deviation - Batch_ records:

  * **Related Object**: _Deviation - Batch_
  * **Outbound Reference Field**: _Deviation_
  * **Quality Team Role**: _Owner_
  * **Application Role**: _Owner_
  * **Status**: _Active_

### Supported Objects

Related Objects to Secure is configurable for the following objects: _APQR_, _APQR Item_, _Assessment Risk_, _Assessment_, _Audit_, _Auditor Profile_, _Auditor Role_, _CAPA Action_, _Change Action_, _Change Action Template_, _Change Control_, _Complaint_, _Containment_, _Continuous Improvement_, _Correction_, _Deviation_, _Effectiveness Check_, _Extension Request_, _Finding_, _Impact Assessment_, _Investigation_, _Issue Escalation_, _Lab Investigation_, _MedTech CAPA_, _Mitigation Action_, _Nonconformance_, _Organization_, _Product Return_, _Proposed Audit_, _Quality Event_, _QMR_, _QMR Item_, _Qualification_, _Quality Incident_, _Risk Event_, _Risk Register_, _Root Cause Analysis_, _SCAR_, _SCN Impact Assessment_, _Supplier Change Notification_, _Test Plan_.

Standard and custom objects related to any of the above objects are also available as _Related Objects to Secure_.

### Limitations for Related Object Security

The following limitations apply to Related Object Security:

* Roles assigned using Related Object Security do not support workflow operations. If workflows require application roles on the secured object, consider configuring a new _Quality Team_ for the related object, or implementing [Dynamic Access Control](/en/lr/33946/) for that object instead.
* VPK issues may occur when [migrating](/en/lr/36919/) a Related Object Security configuration between Vaults. To avoid this, we suggest provisioning a [sandbox Vault](/en/lr/48988/) that matches the configuration of the target production Vault, making Related Object Security configuration changes only in the sandbox Vault, and then importing the _Quality Team_ configuration to the production Vault.

## Power Delete Quality Team Member Assignments {#power-delete}

<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 <em>Power Delete Quality Team Members</em> record action is designed for Admins. The effects of this record action ignore security permissions. We recommend using this action only during configuration and testing, not on active <em>Quality Event</em> records or in production environments.</p>
    </div>
  </div>
</div>



During _Quality Team_ configuration and testing you may need to delete a team's membership assignments on a record in order to make changes to the Quality Team's structure or behavior, however, it may be necessary to preserve the team-enabled record itself. For example, you need to remove a _Quality Team_ role even though there are records that have team member assignments for that role, and those records are critical to preserve as they are part of your environment's test data setup. By default, Vault does not allow you to remove the role (or team) from the configuration of your Vault until all team members have been individually removed from all records.

The _Power Delete Quality Team Members_ record action completely clears a *Quality Team*'s membership assignments for a specific record while preserving the record itself. The action deletes membership assignments only on the current record, regardless of the team or role's inherit configurations. This action also deletes orphaned membership assignments caused by, for instance, changing the type of a _Quality Event_ record that already has _Quality Team_ membership assignments.

### How to Configure Power Delete

You must set up this action individually for each object where you will want to use it. To configure the **Power Delete Quality Team Members** record action:

  1. Navigate to **Admin > Configuration > Objects** and click into the intended object.
  2. In the **Actions** tab, click **Create**.
  3. In the _Create Action_ dialog, select **Power Delete Quality Team Members** in the drop-down.
  4. Click **Continue**.
  5. Optional: Select the checkbox **Available in All Lifecycle States** to make the record action available in all lifecycle states. If selected, Admins can configure Atomic Security to further restrict access to the **Power Delete Quality Team Members** record action.
  6. Click **Save**.
  7. Optional: If **Available in All Lifecycle States** was selected, make selections in the _Atomic Security_ dialog box for object lifecycle states in which this action should be available, then click **Save**.

The _Power Delete Quality Team Members_ record action should now be available on related object records. Note that by default, enabling this record action makes it available on base object types only. You can enable it for additional object types in the **Object Types** tab.

<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>: Disable the <em>Power Delete Quality Team Members</em> record action before performing configuration migrations into production, or opening the Vault for production use.</p>
    </div>
  </div>
</div>



## Deletion Behavior for Records with Quality Team Assignments

While record deletion in Quality Vaults is not common, typically occurring only in a non-production environment, Vault supports the deletion of a record's assigned _Quality Team_ members automatically whenever a team-enabled object record is deleted.

QMS includes additional support for deleting groups of related team-enabled records where the inheritance of team members from a top-level record to lower-level process records may be present. Depending on your Vault's configuration, users with permissions to delete a team-enabled object record may be able to delete the team-enabled record, its assignments, and records related to the team-enabled record and their associated _Quality Team_ assignments with a single delete action. This supports testing environment actions like deleting a _Change Control_ and its related _Change Action_ records, as well as all related _Quality Team_ member assignments, with a single click.

When a user deletes a team-enabled object record with _Quality Team_ assignments, Vault respects the object relationship's [deletion rule behavior](/en/lr/28740/) to determine how other related records should or should not be affected. If the deletion rules indicates to delete the related record, Vault deletes both the related record and its associated _Quality Team Role_ assignments. If the deletion rules permit the related records to exist without the team-enabled record itself, then only the team-enabled record and its assignments will be deleted, with the remaining related records and their assignments unaffected.

## Reporting on Teams

You can report on your _Quality Teams_ and team members to easily assess scope and efficiency. Navigate to **Admin** > **Configuration** > **Report Types** to set up team member reporting. See [About Report Types](/en/lr/39659/) for more information.

## Limitations {#limitations}

  * A Vault can contain up to 100 _Quality Teams_. Each _Quality Team_ can contain up to ten (10) team roles. Each team role can have a maximum of 20 members.
  * Vault does not support _Quality Team_ roles linked to sharing settings roles that use rule-based groups ([Dynamic Access Control](/en/lr/33946/) and [custom](/en/lr/25494/) and [matching](/en/lr/36122/) sharing rules).
  * Vault does not allow the establishment of new team roles against a sharing settings role with any rules, but does not prevent Admins from adding such rules to already established roles that already have team roles for.
  * In the event that an Admin adds rules to a team role's application role, end-users will receive an error when they attempt to **Manage Team** on any object record using that team.
  * You cannot create a _Quality Team_ for an object that has more than one parent object reference, nor can you create a _Quality Team_ for an object under two or more levels of [parent object relationships](/en/lr/28740/).
  * Vault does not allow configuration of a _Quality Team_ for a [child object](/en/lr/28740/).

The following standard _Application Roles_ cannot be selected for a _Quality Team Role_:

  * _Owner_
  * _Process Viewer_
  * _Document Change Control Approver_
  * _Document Change Control Reviewer_
  * _Trainee_
  * _External Collaborator (Audit)_
  * _Learner_
  * _Direct Manager_

## Related Objects & Terms

  * **Team-Enabled Object**: An object you have defined a team for.
  * **Team-Enabled Record**: An object type record that leverages a team.
  * **Quality Team Members Object**: A system-managed object that Vault creates when you create a team. It stores the team role assignments of users for specific team-enabled records.
  * **Quality Team**: This component defines a _Quality Team_ you've created in your Vault. It defines the structure of the team by associating _Quality Team Roles_ and team behavior as a team-enabled record moves through its processes. It is associated to an object or object type in order to declare records of that object or object type to use a team.
  * **Quality Team Role**: A role defining which security rights members have and by which role they are constrained. This component defines the roles that are available or required for object records leveraging the associated _Quality Team_ (Change Owner, Primary Investigator, QA Approver, etc). These roles link to sharing settings roles such as _Owner_, _Reviewer_, and _Editor_. The component further defines the behavior of these roles. For example, you can define the minimum number of users required to complete a team, the maximum number of users allowed on a team, and whether or not you can select users from any group in the Vault or from a specific role on the team-enabled record.
  * **Quality Team Role Membership Restriction**: A component defining a _Role Membership Restriction_ that defines _Team Role_ exclusivity within a specific _Quality Team_. These restrictions are defined manually, with Vault establishing a bi-directional relationship between two roles that are exclusive to one another. For example, you can define a restriction that does not allow a user with the _Owner_ role to be assigned as the _Approver_. Because of the bi-directional role relationship, Vault also automatically restricts the user given the _Approver_ role from being assigned as the _Owner_ without having to define an additional restriction.

## Related Permissions {#permissions}

To view the _Team_ section and to manage team members, users require _Read_ permission on both the relevant team-enabled object and its corresponding _Quality Team Member_ object. For example, to modify team role assignments on a _Deviation_ record, users need _Read_ permission on the _Deviation_ object and the _Deviation Quality Team Member_ 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_][4] configuration.

 [1]: #limitations
 [2]: #power-delete
 [3]: #about-inherit-behavior
 [4]: #locked-states
 [5]: #change-record-state
 [6]: #job-log
 [7]: #lim-linked-role-fields
 [8]: #role-membership-restrictions
 [9]: #create-team-roles
 [10]: #inherit-behavior-supported-objects