Teams in Business Process Manager V8.5, Part 1
Modeling teams with IBM Process Designer
This content is part # of # in the series: Teams in Business Process Manager V8.5, Part 1
This content is part of the series:Teams in Business Process Manager V8.5, Part 1
Stay tuned for additional content in this series.
A team is a new construct in IBM Business Process Manager V8.5 (IBM BPM) for defining sets of users who are authorized to perform actions on processes and tasks. For example, a team is used to define the users that can initiate or terminate processes, work on tasks, complete tasks, or administer processes and tasks.
Teams extend and replace participant groups, which were available in previous releases of IBM BPM (participant groups are deprecated in V8.5). Teams are defined in IBM Process Designer and can be packaged as part of process applications or toolkits. IBM BPM provides end-to-end support for teams from modeling teams, to runtime support with APIs and Process Admin console support, through to support for business users in the IBM BPM business user client, Process Portal.
Process Designer includes modeling support for defining both static and dynamic teams and their corresponding team managers. The following new team-related features are available:
- Team members and team managers: A team includes and relates team members and team managers. When associating a team with a process or task related role, each of these user sets is authorized to perform specific actions. For example, members of a team associated with a task are authorized to work on the task, while the managers of the team are authorized to reassign the task between team members, re-prioritize it, or change its due date.
- Team Retrieval Service: For each team, you can provide a custom team retrieval service to determine both the members of the team and the team managers. This service can invoke other services, such as business rules, database operations, or user repository queries.
- Team Filter Service: This service allows you to filter the user set defined by the assigned team in the context of a given task. While a team is defined and shared globally within a process application, a team filter allows you to derive a filtered team that is specific to the context of a task and its enclosing instance, for example, to support scenarios such as the separation of duties.
API support and administration
If, at runtime, administrators need to change the members of a team or its assigned managers, they can use the Process Admin Console to make the updates. For more information about modifying teams at runtime, see Part 3 of this series of articles.
Changing a team within Process Portal
Process Portal enables business users to work with teams and their tasks. It ensures that users have the appropriate access to tasks and process instances according to the associated team definitions.
For team managers, Process Portal includes the Team Performance dashboard. The Team Performance dashboard provides team managers with a summary of the work across all of the teams that they manage. The dashboard displays all the relevant data for a team and allows the team manager to assign and reassign tasks, and change due date and priority for each task.
You define teams in IBM Process Designer as part of a process application or toolkit. The teams can be either static teams with known users and groups, or dynamic teams where membership is determined at runtime using a Team Retrieval Service.
Defining static teams
Often when you define a team, you know the users and groups that form the team in advance. In such a case, you define a static team according to the following steps.
Creating a team
To define a new team, click the plus sign next to Processes, select Team from the list as shown in Figure 1, and provide a name for the team.
Figure 1. Creating a team
The Team editor opens. By default, the Specify Team Using Service option is deselected and member specification using Standard Members is enabled.
Adding users and groups
To add users and groups to the team, click Add user and Add group in the Members section. These users and groups come from the people directory that is configured for your BPM configuration and the underlying WebSphere® Application Server. In most cases, the people directory is Virtual Member Manager, which is also known as Federated Repositories or a standalone LDAP registry. To verify your security configuration, you can view the global security settings in the WebSphere Integrated Solutions Console.
In the following example shown in Figure 2, the users David and Linda and a group named Region North define the members of the Sales Team team. In practice, groups are often preferred to individual users because any changes to these groups in the underlying people directory are automatically picked up by BPM.
Figure 2. Adding users and groups to a team
Defining a managers team for the team
After specifying the members of the team, you should also assign a managers team. The members of the managers team are usually the team leads or supervisors of the team. By adding them using the managers team, they can use the Team Performance dashboard in Process Portal to manage the workload of the team. For example, managers can use the dashboard to change the due date of a task or reassign an activity to another team member.
Any team can be used as the managers team of another team. That means that a team used as manager team can have its own manager team, thus making it easy to model management hierarchies. However, only the direct team-to-manager-team relationship is relevant for team management actions.
Figure 3 shows that the Region Managers North team is assigned as the managers team for the Sales Team team.
Figure 3. Adding managers to a team
Defining dynamic teams
At modeling time, you do not always know exactly who will perform a task at runtime. In these cases, you can specify a service that dynamically selects users and groups for the team at runtime. To define a dynamic team, you use the Specify Team using Service option and define a Team Retrieval Service as shown in Figure 4.
Figure 4. Defining a dynamic team
At runtime, the Team Retrieval Service is invoked when the team is used, for example, when creating a user task. The result of the service includes the names of the member users and groups and the name of the associated manager team, much like a static team definition.
IBM BPM does not provide a default Team Retrieval Service; instead, you either model a service when defining a dynamic team, or re-use an existing service. A Team Retrieval Service Template is provided for you to create the service implementation. The output parameters of the service are fixed. However, you can add input parameters that are specific to your service, such as the region parameter in the previous example. For each of these parameters, you need to specify an Input Mapping when defining the team. Team definitions are not specific to process instances or business data. Therefore, you can either use constant values or environment variables as input parameters when defining the mapping.
Note that environment variables are defined as part of process application settings. An environment variable can have different values for development, test, staging, and production. Administrators can override environment values at runtime, allowing you even more flexibility in your team configuration.
For more information about creating Team Retrieval Services, see Part 2 of this series.
Using team definitions from toolkits
A team can be defined as part of a process application or toolkit. You can make teams that are defined in a toolkit available to a process application by including the toolkit in the application. Team names do not need to be unique across process applications and toolkits. To distinguish between teams with the same name, a team defined in a toolkit gets the name of the toolkit appended to its name in Process Designer.
Figure 5. Using teams from a toolkit
In the example shown in Figure 5, the toolkitFor2012 toolkit is included in the Sales App process application. The toolkit provides definitions for the Account Team, Audit Team, Sales Team North, and Support Team teams. The process application also includes an Account Team. In the example, teams from toolkitFor2012 can be identified by the "toolkitFor2012" tag after the team name.
Assigning teams to activities
After defining a team, you can use it to define, for example, who can start a business process or who should perform a certain activity. Of relevance here is the ability to assign teams to activities.
Teams can be assigned to human activities of a BPMN process, also called user tasks or simply tasks. When you model a human activity in a BPMN process, then the following options exist to assign people to it:
- Assign a team to a lane.
- Assign a team to an activity.
- Assign a team to an activity by name.
Assigning a team to a lane
The easiest way of defining the team assignment for a set of human activities is to put them all into the same lane and then assign a team to the lane. Starting with lane assignments for activities is a good default team assignment in many cases. Figure 6 shows a simple business process where Sales Team is used as the default team assigned to the lane.
Figure 6. Team assigned to a lane
To benefit from the team definition on the lane, all you have to do when defining an activity is to use whatever assignment has been specified on the lane. Figure 7 shows how to select Lane as the Assign To option in the Assignments section of the property sheet for the activity.
Figure 7. Using the team defined on the lane for team assignment
Assigning a team to an activity
You may have scenarios where your process model has activities that all belong to the same lane, but where you want to be more specific when defining the assignment for a particular task. You can easily override the lane assignment on each activity by assigning the activity to a team instead, as shown in Figure 8.
Figure 8. Assigning a team to an activity
Note that in the example some of the Assign To options are marked as deprecated. While these options still work for existing scenarios, they produce assignments that are not compatible with the Team Performance dashboard that was introduced in IBM BPM V8.5. Therefore, when you model a new process, consider using either the Team or the Lane option.
If you select Team as the Assign To option, the next step is to decide which team you want to use. You can either chose an existing team or create a new one. In Figure 9, the Sales Team North team has been selected for the activity assignment.
Figure 9. Choosing the team for an activity assignment
Assigning a team to an activity by name
Often at modeling time, it is not clear which team should be assigned to a particular activity because the assignment depends on the business context of a particular business process instance. This means that the team can only be determined at runtime by the process itself or by an associated business rule or service.
In IBM BPM V8.5, this type of assignment is a fully supported scenario. Instead of using the static selection of a team, this type of team assignment allows you to assign the team by name.
In the example shown in Figure 10, a salesTeamName variable is defined as part of the process. The Determine Team Name service determines the salesTeamName value based on business data of the process, such as the region. The salesTeamName variable is then used to define the team name for the runtime task assignment for the Offer Submission activity.
Figure 10. Defining a team assignment by name
Note that the teams specified by name must exist when the process runs. If, for example, the Determine Team Name rule decides between the Approvers North and Approvers South team based on the region of the request, then you must ensure that both teams exist and are either part of the process application or one of its toolkits.
Advanced team assignment
So far, this article discussed how to assign a team to an activity. There are scenarios where it is not desirable to assign all members of a team to a certain activity; for example, in separation of duties scenarios, or when an activity should be assigned to a specific user.
Assigning only to a subset of team members
The classic use case for assigning an activity to a subset of team members is in separation of duties scenarios where two or more approval activities are assigned to the same Approvers team. To ensure separation of duties, the process must be modeled so that people from the team who have worked on a previous approval activity of the same process instance are excluded from working on subsequent approvals.
Another use case is skills-based routing. Although all members of a team can usually work on a certain task, only a subset of the team might be qualified because a certain skill level is required, or because a particular authorization is needed, which only few people of the team have.
To support these and similar scenarios, Team Filter Services were introduced in IBM BPM V8.5. Team Filter Services can be associated with an activity. A filter service is similar to a Team Retrieval Service in that it dynamically determines the team members and managers at runtime. However, a filter service uses the team assigned to an activity as its input, and generates a changed team as its output. This team is referred to as a filtered team and is used for assigning the runtime task.
In Figure 11, the Separation of Duties Service is used to determine the team members for the task assignment at runtime. The service uses two inputs for computing the filtered team: the specified team for the task (in this case the team assigned to the lane) and the previousApprover variable of the process.
Figure 11. Filtering a team to enable separation of duties
A Team Filter Service can take instance variables as input parameters, as it is always used in the context of an activity In the example, the previousApprover variable of the process is used as input to the previousApprover parameter that was defined as part of the Team Filter Service interface.
For more information about creating a Team Filter Services, and in particular, separation of duties, see Part 2 of this series of articles.
Assigning an activity to a specific user
A team is often used as a pool from which a specific user is selected at runtime for the activity assignment. By selecting one of the User Distribution options when defining the activity assignment, you can determine how the user is chosen. You might be familiar with the Round Robin and Load Balance options from previous releases. In IBM BPM V8.5, the Last User option was in introduced as shown in Figure 12.
Figure 12. Assigning to the Last User of a team
If this option is used in combination with an Assign To choice of Team, the current task is assigned to the same member of the team who completed the last activity in the process instance. If a corresponding user is found, the task is still associated with the team and initially assigned to the found user. The managers of the team are unaffected. If a "last user" is not found, the entire team is assigned.
In the example, the first and the second activity are both associated with the Sales Team North team. To ensure that the same team member works on both tasks, the assignment for the last activity has the user distribution set to Last User. As a result, when the Offer Evaluation activity is reached, it is automatically assigned to the user that completed the Offer Submission activity.
The Last User in Lane activity assignment option from previous releases is now deprecated. The same behavior can now be achieved by assigning an activity to a lane, and by selecting Last User as the User Distribution option.
This article discussed the new team functionality introduced in IBM BPM V8.5. It described the concepts around teams and how to define both static and dynamic teams. It went on to describe how to assign teams to activities and how at run time business data of a process instance can be leveraged for team filtering. Subsequent articles in this series cover how to design and implement Team Retrieval Services and Team Filter Services, and how business administrators can modify teams at runtime.