A team identifies a group of users and determines who can manage provisioning requests and approval tasks associated with this team. The team definition consists of a list of team requesters, team recipients, and team options, as described below:
A team requester is a user who can administer requests and tasks for the team. Team requesters can be users or groups.
The team recipients are those users who are allowed to participate on the team. Team recipients can be users, or groups within the directory. Alternatively, they can be derived through directory relationships. For example, the list of members could be derived by the manager-employee relationship within the organization. In this case, the team recipients would be all users that report to the team manager.
NOTE:The Provisioning Application Administrator can configure the directory abstraction layer to support cascading relationships so that multiple levels within an organization can be included within a team. The number of levels to include is configurable by the administrator.
The team options determine the provisioning request scope, which specifies whether the team requesters can act on an individual provisioning request, one or more categories of requests, or all requests.
The Provisioning Application Administrator can perform all team management functions.
The teams you define are stored locally in the Designer project’s Provisioning\AppConfig\TeamDefs directory.
Although a team can sometimes refer to a group in the Identity Vault, a team is not the same thing as a group. When you define a group in the Identity Vault, you identify a set of users that have something in common. However, the group does not automatically have the capabilities of a team within the User Application. To take advantage of the team capabilities within the User Application, you must define a team that points to the group.