Configuring Teams (QualityOne)

QualityOne Vaults allow you to create and configure Teams and Team Roles to suit their needs. For example, an Audit might require three (3) team roles to work through from start to finish: a Quality Auditor, a Lead Auditor, and an Approver. Using Teams allows you to dictate that every created Audit requires one (1) Quality Auditor, one (1) Lead Auditor, and between zero (0) to two (2) Approvers in order to begin work.

Teams allow users to make individual work assignments to individual Change Controls, Audits, CAPAs, or other Quality Event-related processes. Users define these assignments directly from the record detail page by selecting individual user assignments from a list of users authorized to perform that role on that record. Teams integrate with object record sharing settings, allowing for a simple experience without sacrificing critical compliance tools.

About Teams Terminology

QualityOne uses the conceptual terminologies to support and define Teams:

• Team-Enabled Object: An object that has Teams activated.
• Team-Enabled Record: An object type record that leverages a team.
• Team Member Object: A system managed object that Vault creates when you activate a team. It stores the team role assignments of users for specific team-enabled records.
• Team: This component defines a Team you’ve created in your Vault. It defines the team’s structure by associating Team Roles and team behavior as a team-enabled record moves through its processes. A Team is associated with an object or object type to declare records of that object or object type to use a “team of members”.
• Team Role: A role defining which security rights team members have and are constrained to. This component defines the roles available or required for object records leveraging the associated Team (Lead Auditor, Approver, etc). These roles link to Application Roles such as Owner, Reviewer, and Editor, and 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 a specific role on the team-enabled record.
• Team Role Membership Restriction: A component defining a Role Membership Restriction that allows for flexible Team Role exclusivity within a specific Team. These restrictions are defined manually, with Vault establishing a two-way relationship between two (2) roles that are non-interchangable. For example, you can define a restriction that does not allow a user with the Manager role to be assigned as the Approver. Because of the two-way role relationship, Vault also automatically restricts the user given the Approver role from being assigned as the Manager without having to define an additional restriction.

How Teams Work

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

• A single object type.
• All object types that do not have a specific Team definition.

You can configure options such as lifecycle state changes that can trigger automated events when defining Teams. You can also lock the membership of all team roles in selected lifecycle states. For example, you might define a procedure dictating that all Audits created in the Pending Team Assignment state have no associated workflows. You can then configure Vault to automatically move the Audit into the Initiated state of its lifecycle once the Quality Auditor and Lead Auditor are chosen. The team completion can even start a workflow, assigning tasks to the team members defined.

Configuration Overview

Configuring your Vault to use Teams involves the following steps:

1. Creating a team definition for the desired object
2. Create team roles for a team definition
3. Configuring linked role fields
4. Creating restrictions for role memberships
5. Configuring team-enabled object actions

Creating Teams

You can create Teams by selecting the appropriate object and object type. Creating Teams involves configuring the following items:

• Creating a team definition
• Changing record states (Team Option)
• Locked states (Team Option)

Creating a Team Definition

To create a team definition:

1. Navigate to Admin > Configuration > 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 when you no longer want to use this team.
5. Select an Object that this Team applies to.
6. Optional: If the object has types, you can select an Object Type. You can have only one (1) Team active per object or type. Once you create a Team, you cannot change this option.
7. Optional: Select the Change Record State when Team is Complete checkbox. See the Team Option for more details.
8. Optional: Select one (1) or more Locked States. See the Team Option for more details.
9. Click Save.

Once you create the Team, Vault updates the relevant object layouts with a Teams section. This object layout section shows team assignments and allows authorized users to select users for roles. We recommend editing your object 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 Team sections without assigned members after you configure the team.

Team Option: Change Record State when Team is Complete

Select this checkbox to activate Start State and Destination State fields for configuration. This option allows moving an object record to a new state upon completing the minimum Team membership. This state change also triggers any associated automated events, such as auto-starting workflows. Vault completes this event for an object record when:

• The team has at least one (1) team role which Minimum Required Users have at least one (1) value.
• All roles which have Minimum Required Users defined have that number of assignments met.
• A user updates the team members and the record is in the defined Start State.

Team Option: Locked States

When the associated object record is in one (1) of these specified locked lifecycle states, no user in the Vault may make changes to the membership of this 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 the “end-of-life” states of records’ lifecycles, where assignment information must be retained.

Deleting Teams

You cannot delete a Team definition if any record which uses that team has any team member assignments. To delete a Team definition, you must first remove all Team members on all records which use it. To simplify this process, you can also use the Admin-only Power Delete Team Members record action to remove all Team members from the record. You can make this action available in the appropriate team-enabled object for ease of access.

To delete a team definition:

1. Navigate to Admin > Configuration > Teams and select the appropriate Teams definition required.
2. In the definition’s Actions menu, click Delete.
3. Click Continue to save your changes.

Creating Team Roles

After defining your Team, you can also create Team Roles while configuring the roles with several options. Since Vault associates Team Roles directly with Application Roles, ensure you add any additional application role required before creating team roles.

To create a team role:

1. Navigate to Admin > Configuration > Teams and select the Team needed.
2. In the Team Roles section, click Create.
3. Enter a Label and Name.
4. Select a Status.
5. Select an Application Role. 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 Limitations for more details regarding the Application Roles that cannot be assigned to a Team Role.
6. Optional: Enter Help Content. This will appear to all users who hover over the role label in the Team section of the associated object record detail page.
7. Optional: Select the Minimum Required Users for this role. Leaving this field empty or selecting zero (0) will indicate that the Team membership may be completed with this role unassigned. You can select a minimum of zero (0) to 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 restricted to members not assigned multiple roles. A team member in an exclusive role cannot be a member of any other role on the same team for a given object record. You can also configure flexible limitations on role exclusivity using role membership restrictions.
10. Optional: In the Linked Field drop-down, select a User object reference field from team-enabled objects. The value of the selected field is mapped to the User assigned in this Team Role of that object record. This option can only be used if this Team Role has a Maximum Users value of one (1). See Linked Role Fields for more details.
11. Optional: Select a Constraining Role to allow Vault to populate the Team assignment options with only users in the selected role. 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. Select Inherit From Events to allow Vault to check the value of the configured Inherit From Events field on this role. This option is available only on supported objects. See About Inherit Behavior for more details about these options.
13. Optional: Select an object reference field to specify the object from which to inherit the role in Inherit From. This field is required if you selected Inherit in the Inherit Behavior field. This field value determines how this Team Role finds a record from which to inherit its membership.
14. Optional: Select one (1) or more object reference fields to specify the object from which to inherit the role in Inherit From Events. This field is required if you selected Inherit From Events in the Inherit Behavior field. This field value determines how the Team Role finds a record from which to inherit its membership.
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.
16. Click Save.

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

Reordering Team Roles

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

To rearrange roles, click Reorder. Then, click and drag the roles by their shaded top left corner. Once you’re done reordering, click to Save your changes or Cancel to discard. You cannot create or reorder roles while editing the Team definition.

About Inherit Behavior

Populating the Inherit Behavior field when creating the Team Role determines the Team Role’s inherit behavior, while the Inherit From and Inherit From Events fields specify from which object record the Team Role inherits team membership. Fields configured on the team-enabled object that reference other team-enabled objects are available to select in the Inherit From and Inherit From Events fields.

The Team Role checks for a value in the Inherit From or Inherit From Events field in these cases:

• You select the Inherit or Inherit From Events behavior in the Inherit Behavior field.
• On record creation.
• A user clicks Restore while managing a team.

If the value of the Inherit From or Inherit From Events field is an object record with a Team definition, this Team Role will inherit the membership from that record’s team’s role (matched based on having the same Application Role configuration). If no such record exists, the record has no team, or the record’s team has no role linked to a matching application role, no inheriting occurs.

Users can still manually edit a Team Role’s membership with inherit behavior enabled. In addition, enabling inherit behavior provides users managing the team with a Restore option. With inherit behavior enabled, 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.

Inherit From Events Supported Objects

The Inherit From Events option is available to select from the Inherit Behavior field when configuring Teams on the following objects:

• Action Item
• CAR
• Effectiveness Check
• Extension Request
• Investigation
• Root Cause
• Root Cause Analysis

Fields configured on the team-enabled object that reference the following team-enabled objects are available to select in the Inherit From Events field when creating a Team Role:

• Audit
• Audit Finding
• Change Control
• Complaint
• Continuous Improvement Initiatives
• HSE Event
• Lab Investigation
• NCR

About Linked Role Fields

Using the Linked Field option in a Team Role definition allows Team Role assignments to display in related lists, searches, filters on library views, reports, and anywhere a User object reference field may be accessible in Vault. Once linked to a team role, users or Vault may not update a given object reference field, other than directly editing the linked Team Role. 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 not instantly updated. See the limitations for linked role fields before deciding to implement them in your Vault.

Configuring Linked Role Fields for Teams

To configure the linked role field functionality:

1. Create a User object reference field on the team-enabled object needed. If the object supports object types, ensure you associate the field to the same object type as the Team definition.
2. Navigate to the appropriate Team Role definition required and click Edit.
3. In the Linked Field drop-down, select the User object reference field created earlier in step 1.
4. Click Save.

As the linked role field’s functionality may not be apparent to users viewing the team-enabled object record, we recommend you to do the following:

• Do not add the linked role field to the team-enabled object layout or configure security to prevent users from trying to manually edit the linked field. Once linked to a role, Vault prohibits edits to the field value. There is no need to present non-editable fields as editable to users.
• 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 users know they cannot manipulate the 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, you can choose an update strategy to sync existing records’ fields to match their pre-existing assignments’ values. When syncing existing records, affected records may have their linked field’s values changed; you can check the Audit Trail for details on the modification.

This section is optional: if your organization chooses to keep pre-existing records untouched, you can skip this section. If you want to update pre-existing records, Vault provides the following methods:

• To update all team-enabled records, click Sync Linked Role Fields on the Team definition. This button is available once you select a Linked Field in one (1) of the team’s role definitions. Running the Sync Linked Role Fields action 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 an individual or a subset of records using a given team, you can also configure this action as a standard object action.

Job Log: Sync Linked Role Fields

The Sync Linked Role Fields process provides a job log, which lists the following information:

• Each team-enabled record that had an assignment.
• If Vault successfully updated the team-enabled record.
• If any errors were encountered.

The job skips any records that it cannot update. For example, a role definition previously had a Maximum Users value of more than one (1) but then an Admin changed that value to one (1) before selecting a value in Linked Field. If there were existing records with Teams that have more than one (1) assignment in that role, this job cannot sync the linked role fields for those assignments or records and would list that error in the resulting job log.

Creating Role Membership Restrictions

After defining Team Roles for a Team definition, 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 you to define a more specific restriction for each role within a Team so that a user may be selected for more than one (1) role on the Team while simultaneously providing exclusivity for specific roles where it is required.

A Team must have a minimum of two (2) active Team Roles defined for this configuration to display. A Team can have a combination of unique membership restrictions. For example, a “Manager” Role item is setup with an “Approver” and a “QA” Is Exclusive With item (created as separate row items), while a “QA” Role item can be setup with an “Approver” Is Exclusive With item in another row.

To create role membership restrictions:

1. Navigate to Admin > Configuration > Teams and select the Team needed.
2. Click Edit.
3. In the Role Membership Restrictions section, click Add Restriction. This button only appears if at least two (2) active Team Roles exist which do not have Exclusive Membership? enabled.
4. Select a Role. Team Roles with Exclusive Membership? enabled displays as an unselectable item.
5. Select a value for Is Exclusive With. You cannot select the same team member as in the Role field of the same row.
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.

The new Role Membership Restriction appears in the list at the bottom of the Team definition page. If the status is set to Active, Vault automatically applies the restriction to all existing records for the associated object.

Configuring Team-Enabled Object Actions

All team-enabled objects contain the following actions:

• Power Delete Team Member: triggers Vault to completely clear a Team’s membership assignments for a specific record. Membership assignments are removed only on the current record regardless of the Team or Team Role’s inherit configurations. This action also deletes orphaned membership assignments. During Team configuration and testing, you may need to delete a Team’s membership assignments on a record in order to make changes to the Team’s structure or behavior. For example, you need to remove a Team Role even though there are records that have team member assignments for that role. By default, Vault does not allow you to remove the role (or team) until all team members have been individually removed from all records.
• Sync Linked Role Fields: triggers Vault to force an update of an established team member assignment with a member configured from the Linked Field mapping of a team’s role definition. This action appears once you select a Linked Field in one (1) of your team’s role definitions. You may want to use this action if you require a precise individual record update instead, for example, applicable team-enabled records that you do not want to update because they are already closed or locked.

You must set up these actions individually for each object where you will want to use them. By default, enabling these actions makes them available on base object types only. You can enable them for additional object types in the Object Types tab.

Depending on your business needs, you can add these actions as a record action on any team-enabled object:

• Power Delete Team Member
• Sync Linked Role Fields

Reporting on Teams

You can report on your 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 for more details.

Limitations

• Vault does not support Team roles linked to Sharing Settings roles that use rule-based groups (Dynamic Access Control and custom and matching sharing rules).
• Vault does not allow the establishment of new team roles against a sharing settings role with any rules but does not prevent you from adding such rules to already established roles that already have team roles.
• In the event that you add rules to a team role’s application role, your users will receive an error when they attempt to run the Manage Team action on any object record using that Team.
• You cannot create a Team for an object that has more than one (1) parent object reference, nor can you create a Team for an object under two (2) or more levels of parent object relationships.
• Vault does not allow configuration of a Team for a child object.
• You cannot create a Team for an object with a number prefix in the object name.
• The Maximum Users value in the Team Role definition must not be more than one (1) when using linked role fields.
• A team role can only be linked to a single linked role field.
• While a single linked role field can be linked to several teams, only one (1) role on a given team can be linked to the same field.
• The following limits apply to Teams creation:
  • 100 Team definitions per Vault
  • 10 Team Roles per Team
  • 20 team member assignments per Team Role
• You cannot select the following Application Roles for a Team Role:
  • Owner
  • Process Viewer
  • Document Change Control Approver
  • Document Change Control Reviewer
  • Trainee
  • Learner
  • External Collaborator
  • Direct Manager

Configuring User Permissions

You must ensure users have the appropriate read and create permissions to access the appropriate objects and object fields in addition to the permissions outlined below:

• The Application Role object: Read permission.
• The Team-Enabled Objects: Read permission to view the Teams section and team-enabled records.
• The Team Member Objects: Read permission to view and modify Team members in the intended team-enabled objects.
• The ability to edit Teams on team-enabled objects in a given lifecycle state also depends on the lifecycle’s Atomic Security on Relationships or locked state configuration.

If you configured DAC on these objects, users can only see records on which they have Read permission.

Related 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:

Type	Permission	Controls
Security Profile	Admin: Configuration: Objects: Read	Ability to create and modify Vault objects.
Security Profile	Admin: Security: Users: Read	Ability to view all users.