# Configuring Teams (QualityOne) [QualityOne Vaults](/en/lr/78610/) allow you to create and configure [_Teams_](/en/lr/70759/) and _Team Roles_ to suit their needs. For example, an _Audit_ might require three 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 Quality Auditor, one Lead Auditor, and between zero to two 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](/en/lr/70759/#assigning-users-to-a-team) 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](/en/lr/25494/), allowing for a simple experience without sacrificing critical compliance tools. ## About Teams Terminology {#about-terms} 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_][11] 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][6] 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_][12] 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 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 {#how-teams-work} You can create a _Team_ for any non-system object, with some [limitations][7], 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 {#overview} Configuring your Vault to use Teams involves the following steps: 1. [Creating a team definition for the desired object][11] 2. [Create team roles for a team definition][6] 3. [Configuring linked role fields][4] 4. [Creating restrictions for role memberships][12] 5. [Configuring team-enabled object actions][9] 6. [Configure a _Teams Bulk Management_ tab][14] 7. [Secure related objects][15] 8. [Optional: Configure reporting][16] 9. [Configure user permissions][17]
## Creating Teams {#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][1] * [Changing record states (Team Option)][2] * [Locked states (Team Option)][3] ### Creating a Team Definition {#create-team-def} 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 _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][2] for more details. 8. Optional: Select one or more **Locked States**. See the [Team Option][3] 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](/en/lr/26387/) 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 {#change-record-state} 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 team role which *Minimum Required User*s have at least one 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 {#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 _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 {#delete-team} 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][9] record action to remove all _Team_ members from the record. You can make this action [available](/en/lr/43127/) 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 {#create-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_](/en/lr/36440/), 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][7] 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 will indicate that the _Team_ membership may be completed with this role unassigned. You can select a minimum of zero 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][12]. 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. See [Linked Role Fields][4] 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][13]. See [About Inherit Behavior][5] 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 or more [object][13] 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 {#reorder-roles} If you have created more than one 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 {#cascade-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 {#events-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 {#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][7] for linked role fields before deciding to implement them in your Vault. ### Configuring Linked Role Fields for Teams {#config-linked-role} 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][6], 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 {#add-linked-role-fields} 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 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][8]. * 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][9]. ### Job Log: Sync Linked Role Fields {#job-log} The _Sync Linked Role Fields_ process provides a [job log](/en/lr/24762/), 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 but then an Admin changed that value to one before selecting a value in _Linked Field_. If there were existing records with _Teams_ that have more than one 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 {#role-mem-restrict} After defining [_Team Roles_][6] 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 role on the _Team_ while simultaneously providing exclusivity for specific roles where it is required. A _Team_ must have a minimum of two 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 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 {#team-enabled-action} 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][10]_ mapping of a team's role definition. This action appears once you select a _Linked Field_ in one 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](/en/lr/43127/) on any team-enabled object: * _Power Delete Team Member_ * _Sync Linked Role Fields_ ## Configuring a Teams Bulk Management Tab {#bulk-tab} To manage _Team Role_ assignments in bulk, you must navigate to **Admin > Configuration > Tabs**, activate the _Teams Bulk Management_ tab, and add it to an existing [tab collection](/en/lr/542174/). ## Securing Related Objects {#related-object-security} _Team_ definitions let you assign users to roles on specific team-enabled records, which may have relationships to other object records that are not team-enabled. By default, only the user who created those related records can edit or delete them. The _Related Objects to Secure_ option within a _Team_ definition can allow more flexible access to non team-enabled records in cases where users are replaced in a _Team_ on the main record. For example, the _Owner_ of an _NCR_ record adds a related _Action Item_ record to the _Action Items_ section. While the _NCR_ 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 access on the related _Action Item_ record. On an _NCR_ record, the following [_Related Objects to Secure_ definition][18] would provide the _Owner_ team member with an _Owner_ role in the Sharing Settings of any related _Action Item_ records: * **Related Object**: _Action Item_ * **Outbound Reference Field**: _NCR_ * **Team Role**: _Owner_ * **Application Role**: _Owner_ * **Status**: _Active_ The related object to secure: * Can be a standard or custom object that has a [raw](/en/lr/62987/) or standard data store method * Cannot have an active _Team_ definition * Must have an [outbound relationship](/en/lr/28740/#how-to-view-relationships) to the team-enabled object * Cannot be a team member object (for instance, _Audit Team Member_), a signature object (for instance, _APQR Signature_), or an external collaboration user assignment object (for instance, _Ext Collab Action Item Assignment_) While assigning users to roles through a _Related Objects to Secure_ definition can provide edit and delete access on specific records, you must also grant users the relevant object-level permissions for the related object. If the related object uses [Dynamic Access Control](/en/lr/33946/), you must additionally 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 some cases, roles assigned through Related Object Security display with a checkmark in the _Application Override_ column. ### Supported Objects Related Object Security is configurable for standard and custom objects related to the following objects: * _Action Item_ * _APQR_ * _APQR Item_ * _Audit_ * _Audit Finding_ * _Auditor Profile_ * _Auditor Role_ * _CAR_ * _Change Control_ * _Complaint_ * _Continuous Improvement Initiatives_ * _Effectiveness Check_ * _HSE Event_ * _Extension Request_ * _Investigation_ * _Lab Investigation_ * _NCR_ * _Organization_ * _Proposed Audit_ * _Risk Analysis_ * _Risk Event_ * _Risk Register_ * _Risk Study_ * _Root Cause Analysis_ * _Supplier Notification_ ### Defining Related Objects to Secure {#defining-related-objects} To define related objects to secure on a _Team_ definition: 1. Navigate to **Admin > Configuration > Teams** and click into a _Team_ definition. 2. Click **Edit**. 3. In the _Related Objects to Secure_ section, click **+ Add Object**. The _Related Objects to Secure_ section displays only on _Team_ definitions that have at least one _Team Role_. 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 **Team Role** on the team-enabled object which defines the mapping. 7. Select the **Application Role** which defines the access that the _Team Role_ should have. This must be an active role on the team-enabled object. The _Owner_ and _Editor_ roles are only available to select for objects with a lifecycle, and the _Viewer_ role is only available on objects that do not have a lifecycle. 8. Select a **Status**, either _Active_ or _Inactive_. _Inactive_ definitions do not provide any access to the related record. 9. Repeat steps 3-8 to create additional _Related Objects to Secure_ definitions. 10. Click **Save**. ## Reporting on Teams {#reporting} 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](/en/lr/39659/) for more details. ## Limitations {#limitations} * Vault does not support _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 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 parent object reference, nor can you create a _Team_ for an object under two or more levels of [parent object relationships](/en/lr/28740/#parent-child-relationships). * Vault does not allow configuration of a _Team_ for a [child object](/en/lr/28740/). * 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 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 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 {#user-perm} You must ensure users have the appropriate read and create [permissions](/en/lr/22824/) to access the appropriate objects and object fields in addition to the permissions outlined below: * 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](/en/lr/47850/#configuring-atomic-security-on-relationships) or [locked state][3] configuration. If you configured [DAC](/en/lr/33946/) on these objects, users can only see records on which they have _Read_ permission. To manage _Team_ assignments in bulk, Business Admins require the following permissions: * _View_ permission on the _Teams Bulk Management_ tab. * _View_ permission on the _Teams Bulk Management_ page. ## Related Permissions {#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](/en/lr/22824/):
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.
[1]: #create-team-def [2]: #change-record-state [3]: #locked-states [4]: #linked-role-fields [5]: #cascade-behavior [6]: #create-team-roles [7]: #limitations [8]: #job-log [9]: #team-enabled-action [10]: #add-linked-role-fields [11]: #creating-teams [12]: #role-mem-restrict [13]: #events-objects [14]: #bulk-tab [15]: #related-object-security [16]: #reporting [17]: #user-perm [18]: #defining-related-objects