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 managers, team members, and team options, as described below:
The team managers are those users who can administer requests and tasks for the team. Team managers can also be given permission to set proxies and delegates for team members. Team managers can be users or groups.
The team members are those users who are allowed to participate on the team. Team members can be users, groups, or containers 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 members 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 managers can act on an individual provisioning request, one or more categories of requests, or all requests. The team options also determine whether team managers can set proxies for team members or set the availability of team members for the purpose of delegation.
NOTE:The User Application only supports a single level for proxy assignments. Proxy assignments are not propagated to multiple levels.
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. The filenames are derived from the object key with the .team extension. At ment, the
Differences between teams and groups 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.
A team request object specifies the requests that a provisioning team can work on. The request rights specify the actions that team managers can perform on the provisioning requests and tasks.
The team definition has a one-to-many relationship with team request objects. This means that each team must have at least one team request object defined for it, but it can have more. Each team request object is associated with only one team definition.When you configure the team request object, you configure the task scope and permissions for the team manager.
The task scope options define the manager’s ability to act on tasks:
Where a team member is an addressee
Where a team member is a recipient
WARNING:For security reasons, the recipient task scope option is disabled by default. Giving a team manager the ability to act on tasks where the recipient of the request is a team member can raise several security issues. First, the manager is then able to view data included on any of the forms that are displayed during the course of workflow execution, regardless of his or her trustee rights. Second, depending on the permission options (see below), a team manager could circumvent the approval process by claiming or approving the task, or by reassigning it to someone else.
The permissions options define the team manager’s ability to:
Initiate a provisioning request on behalf of a team member.
Retract a provisioning request on behalf of a team member.
Make a team member a delegate for other team members’ provisioning requests.
Claim a task for a team member who is a recipient or addressee (based on the task scope).
Reassign a task for a team member who is a recipient or addressee (based on the task scope).
If both of the task scope options are disabled, the team manager cannot view or act on any active requests. Therefore, you must enable at least one of the Permissions options for the team manager.
NOTE:The User Application only supports a single level for delegate assignments. Delegate assignments are not propagated to multiple levels.
The trustee rights defined for a provisioning request apply to team managers who want to initiate a request on behalf of their team members. If the team manager does not have the trustee rights to a provisioning request definition, the team manager cannot make the request because the User Application does not display the provisioning request.
You can define a team that allows managers throughout an organization to control the provisioning environment for their direct reports. If defined properly, a single team definition can be used to allow all managers to control the activities of their direct reports. This means that you do not need to define a separate team for each reporting relationship.
Here are the basic requirements for a team that supports direct reports within an organization:
The members of the team are defined by the Manager-Employee relationship.
The managers of the team are defined by a dynamic group that searches subcontainers, using a a search filter that retrieves only the managers.
After the team has been defined, the User Application allows all managers to use the team management actions within the navigation menu. This gives the managers the ability to control the provisioning activities that their direct reports can perform.
For details on how to define a team to manage direct reports, see Section 10.2.3, Creating a Team to Manage Direct Reports.