When designing a process in IBM Business Automation Workflow, one important step is defining who can initiate the process and who is responsible for executing the various tasks and services you've created. To manage this, you organize users into teams and assign work items based on responsibilities. This blog post explores several ways to populate teams with users and groups, helping you streamline access control and collaboration within your process applications.

Note:

The concepts and practices discussed in this blog post regarding team management in IBM Business Automation Workflow, as authored in Workflow Center, are equally applicable to IBM Cloud Pak for Business Automation when using Business Automation Studio.

1 Teams

Teams in IBM Business Automation Workflow (BAW) represent groups of users who are authorized to perform specific actions—such as working on tasks, initiating processes, or accessing dashboards. Teams are leveraged across end-to-end processes to effectively distribute and manage work.

They are defined within a Process Application in the Workflow Center, and their members can be specified in two main ways:

• As static members
• Through a service

1.1 Teams defined by users and groups (static members)

Static members can be either users directly or groups, which fall into two categories:

• Security groups: Imported from a connected LDAP directory.
• Internal groups: Created and managed within the Process Admin Console.

Define a team "HiringManagers" with users or groups

1.1.1 Security groups

LDAP groups are synchronized into the Business Automation database and become security groups. When a user logs in, their LDAP group memberships are verified and updated if needed. You can also trigger synchronization manually using the REST API endpoint /system/groups_sync.
API Reference( https://www.ibm.com/docs/en/baw/25.0.x?topic=apis-operations-rest-reference).
 

The IBM Business Automation Workflow operations REST API under https://<host>/bpm/explorer

Groups can be nested in LDAP but in IBM Business Automation Workflow they are flattened. LDAP groups are created with all their members as security groups independent of each other. Changes to an LDAP group affect all teams that use that group—regardless of the Process Application or snapshot.

1.1.2 Internal groups

Internal groups are created and managed in the Process Admin Console. Any changes to their membership (adding or removing users or groups) immediately affect all teams that include the internal group.

Process Admin Console Group Management

For more information of the different group types look here: https://www.ibm.com/docs/en/baw/25.0.0?topic=groups-group-types

1.2 Teams defined by a service (team retrieval service)

A team retrieval service dynamically calculates team members when a task assigned to that team is created.

Key characteristics:

• The result of a team retrieval service is local to a specific Process Application snapshot.
• Any changes to the team membership affect all work items using that team within the snapshot.

"GeneralManagerTeamRetrieval" team defined by a service

You can manually add or remove users/groups for such teams on the Team Binding page. However, after making manual changes, the “Automatic refresh enabled” flag should be disabled to prevent the service from overwriting your changes during the next task creation.

Process Admin Console Team Binding Page for Process Application “Hiring Sample”.

Note:
This team retrieval service is executed only if the “Automatic refresh enabled” flag is set (enabled by default) in the Team Binding page of the Process Admin Console.

Tip: You can explicitly trigger the team retrieval service by toggling the “Automatic refresh enabled” flag off and back on.

1.3 Tasks with a team filter service

A team filter service allows you to dynamically filter or redefine the team assigned to a task at runtime. This service runs each time a task is created and only affects that specific task.

How It Works:

• The service receives the original team (from the lane) as input.
• You can modify the team by adding/removing users or groups, or by defining a completely new team.
• The result must be a valid team object, which is then assigned to the task.

This approach provides fine-grained control over task assignments without affecting other tasks or teams.

Team filter service specified for “Review new position request” task.

For more details, see Setting up a team filter service. https://www.ibm.com/docs/en/baw/25.0.x?topic=flow-setting-up-team-filter-service

2. Design decisions for your team

How you define your team members depends on how you plan to manage them later and how user management is handled in your organization. Consider the following:

• Is work assigned to a fixed group of people, or does it vary?
• In your organization work assignments are aligned to LDAP groups?
• Who should be able to change access rights for users?
• Should changes apply only to a specific Process Application snapshot, or should they have a global effect?
• Does task distribution depend on the task type or other patterns?

2.1 Users as standard members

The simplest way to define team members is by adding users directly via the standard member configuration. This is ideal for demos or quick tests. However, these users must exist in the system where the team is authored. If you later install the Process Application snapshot on a Process Server, the same users must exist there—otherwise, the team will have no members.

Note:
You can always modify team members in the Process Admin Console > Team Binding page. These changes are local to the snapshot.

Team Binding Page in Process Admin console for “Hiring Sample”.

Note:
Team bindings from one snapshot can be copied to another using the REST API:
/std/bpm/containers/{container}/version/{version}/team_bindings/sync

Team Binding REST API calls in IBM Business Automation Workflow Operations (https://<host>/bpm/explorer)

2.2 Security groups as standard members

(Best for stable groups of users)

If your organization assigns work based on LDAP groups, you can use imported security groups directly in teams. This approach integrates your company’s permission model into the workflow. Group membership and access rights are managed by your LDAP administrator.

For example, consider a dedicated group within your company responsible for handling customer complaints. These individuals are identified as "Support Engineers" in your organization's LDAP directory. Membership in this group is managed centrally by the LDAP administrator, based on directives from management. This means that adding or removing team members is handled outside of Business Automation Workflow, ensuring that team composition reflects organizational decisions without requiring changes within the workflow environment.
Be aware of how group membership is synchronized into the Workflow database to ensure changes are reflected as expected.

Tip:
If your authoring environment is not connected to the production LDAP, you can create an internal group to represent the LDAP group. When the snapshot is installed on a Process Server, the system resolves group names. If a matching security group exists, it is used; otherwise, an internal group with the same name is created.

Note:
Internal groups can later be migrated to security groups when the corresponding LDAP group becomes available. Use the REST API:
/system/groups_sync
IBM REST API Reference (https://www.ibm.com/docs/en/baw/25.0.x?topic=apis-operations-rest-reference).

2.3 Internal groups in teams

(More flexible, easily changeable)

Internal groups are managed in the Process Admin Console by the IBM Business Automation Workflow administrator. If you prefer not to rely on LDAP groups, or at least not directly, internal groups offer flexibility. They can include users, security groups, or other internal groups.

Using internal groups in teams allows you to:

• Modify team members per snapshot via the Team Binding page.
• Apply changes across all snapshots by updating the internal group in the Admin Console.
• Use REST APIs to manage group membership:
  /rest/bpm/wle/v1/group/{groupname}?action=addMember&user={username}

Continuing with the support engineer example, your organization might maintain multiple LDAP groups to represent support teams across different regions or specialized areas of expertise. These groups can change frequently due to regional shifts, team restructuring, or evolving support topics. In such dynamic environments, managing team membership directly through LDAP can become complex. This is where internal teams in Business Automation Workflow offer a flexible solution: by creating a team like "Support Engineers" in the Process Admin Console, you can easily add or remove the relevant LDAP security groups as members. This approach allows you to adapt quickly to organizational changes without modifying the process logic or relying on LDAP administrators for every update.

2.4 Team retrieval service

(Dynamic team assignment based on parameters)

A Team Retrieval Service runs each time a task is created and assigned to a team. It can use e.g. user attributes, environment variables, exposed process value (EPV) or access external systems (e.g., databases) to determine team members dynamically.

Example:
In a "follow-the-sun" support model, team assignments shift dynamically to align with active working hours across global regions. For example, a service might use tw.local.region and the current time to determine which team should handle incoming work. Every 12 hours, the active region changes, and with it, the team responsible for processing tasks. In this setup, team membership is frequently updated based on time of day, ensuring that new tasks are always assigned to users who are currently available and working. This approach enables seamless global coverage and efficient task distribution without manual intervention.

Tip:
You can also implement this logic using an undercover agent that periodically updates a team directly or internal group membership.

Sample implementation of a team retrieval service.

Setup of the team ”GeneralManagerTeamRetrieval“ with a service and input mapping.

Note:
Avoid using team retrieval services for exposed items like dashboards or processes, as the service does not run when these are accessed (e.g., via Process Portal). In such cases, use e.g. an undercover agent to trigger a service, if you need dynamic team assignment. Team retrieval services are best suited for task assignments.

2.5 Team filter service

(Task-specific team assignment)

A team filter service runs for each newly created task and assigns users specific to that task. This is useful when each task requires a unique set of assignees.

For example, in an approval task, a user may require an approver from their own team—excluding themselves. In this case, a team filter service can be used to dynamically identify and return the appropriate approvers by evaluating the user's team membership and filtering out the current user. This ensures that the task is assigned to a valid team member who is authorized to approve, while maintaining separation of duties.

Implementation of a sample team filter service.

3. Summary

• Use security groups when your LDAP provides the necessary groups and you don’t need to modify them yourself.
• Use internal groups when you want to manage membership within the Process Admin Console, allowing dynamic updates by adding and removing users, internal groups or security groups.
• Use a team retrieval service when team members need to be calculated dynamically per task or based on time/events. Consider an Undercover Agent for time-based or event-based updates.
• Use a team filter service when each task requires a unique subset of team members.