IBM Business Automation Workflow Assignments and Priorities — Part 2 Development

This article looks at the practical elements of implementing assignments.

Photo by Joey Kyber from Pexels: https://www.pexels.com/photo/time-lapse-cars-on-fast-motion-134643/

Introduction

In part 1, we looked at an analyst's questions. This article will look at the implementation mechanics and patterns to implement assignments in Business Automation Workflow.

Teams

Teams are the foundation building block for task assignments. They are a collection of users that determine who will complete tasks when mapped to assignments. Teams are very flexible. They are configurable in two ways, one based on "Users or groups" and two based on "a service."

We recommend that when considering the user of “User or Groups” assignment model you should always use groups,assigning users in the process designer is not recommended. Establish groups even when they will be as small as one or two users. Changing users in the team list requires a redeployment of code while groups are managed external to the process.

The service model for assignments used less than the Users and Groups. Use services when retrieving group data from external sources other than a security registry, for example, building a Team of users from a service call to SAP. Using workflow groups containing security registry groups and or users from an enterprise security registry is the typical way teams are defined. Figure 1 shows a visualization of this structure (Team -> Group -> Group or Users).

Figure 1 BAW Team to Workflow Group and security groups and users preferred mapping model.

Not shown in Figure 1 is the Team to user link option. We strongly recommend not doing this. Not even in development.

Take the following steps to prepare a team for the assignment.

• Map the groups from the security registry to the workflow group. If an appropriate group does not exist, work with the security team to create a group that meets the business need.
• Once the group mappings are understood, create the Group in the IBM Business Automation Workflow Admin application, as shown in Figure 2.

Figure 2 Process Admin Group management

1. Select Group Management from the Process Admin Application menu.
2. Select the New Group, and this will pop a modal view. Enter the group name and the description.
3. Consider a naming pattern for your groups at this level.
4. Add groups or users from the user registry.
5. The Group added, in this case, is the Reviewer.

As you add groups within Process admin and from the security registry it can become confusing which groups are registry groups and which groups are process admin groups, we recommend the adoption of a simple naming convention early to distinguish the two. Such as a simple sufix (ie wg) that distinguishes the workflow groups from registry groups.

• Create the Team in the Process Designer and add the Group (s) to the Team (Figure 3).

Figure 3 Team Editor in process designer

1. Describe the Team; this can help projects avoid multiple teams trying to complete the same purpose.
2. Shows the Group we created earlier added into the groups
3. Links to the management team for this Team. The management team is also a team with a group linked in the same fashion.

This covers the basics of teams, and provides you with what is needed for understanding of the assignments and priorities discussion that follows.

Final key tips for Teams include:

Use enterprise Identity and Access Management systems/processes to manage the adding and removing of users in groups, prefer to use groups from the security registry. Doing this means that workflow administrators have no overhead when people join and exit the organisation. Should using groups from an enterprise registry not be possible then make sure that the the workflow administrators complete the addition and removal of users.

Ensure that Teams are assigned a managing team. Team Managers have permissions to assign and reassign tasks to the managed team (see Team Performance Dashboard in the knowledge center)

Assignment Fundamentals

Set the Task assignment in the assignments tab of the task configuration (Figure 4).

Figure 4 Assignments Basics

1. Assign to: allows the developer to set the Team to do the work. There are two options in this configuration "Lane" and "Team." "Lane" means that the Team assigned on the swim lane is the assigned Team.
2. User distribution: defaults to the recommended push model of "None." The other options are "Last user," "Round Robin," and "Load Balanced."
3. Team filter service: Provides a configuration to set a service to allow the assigned Team to be customized based on process data.
4. Experts team: Define a team of experts at design time.

A quick look at the "Assign to" shows that Lane or Team-Based assignment options are possible (Figure 5). It has been my experience that Lane based assignment is best; it reinforces the expectation of people viewing the process diagram that the tasks in a specific lane are acted on by the persona of the lane.

While that is my preferred model I have seen practices in development groups that do not adhere to this practice. So best to not assume and always verify the assign to method on the task.
Also note that the LastUser in lane assignment will only work with Lane based assignment.

Figure 5 Task "Assign To" options

Distributions

As discussed in Part 1, there are multiple distribution options. Still, we strongly recommend using None to take advantage of a pull model and avoid the pitfalls of push distribution models. Two exceptions are that of Last User and Direct user-selected assignment.

Last User In Lane

Last User in Lane is a simple no-code scenario assignment model that allows assignment to the process creator or the user who completed the previous Task in a swimlane.

• Request Task 1 is assigned based on the None distribution model, meaning whoever claims it first will complete the Task. The user that claims the first Task will automatically be assigned the Notify Request Task 2 later in the flow.

Figure 6 The second activity is configured for the Last User distribution.

1. When the process starts in this case, the user (Sally) claims the task "Request Task 1" when complete, the Task moves to the next step.
2. The approver completes their action, and the Task moves to the next step.
3. Because the last user distribution model is applied, the same user (Sally) as in step 1 is assigned the task "Notify Request Task 2".

Last user in lane is also used to assign the first activity of a process to the process initiator. When used in this way the task is assigned to the person who started the process.
Last User in lane could become problematic if Sally is not available when the the subsequent task is assigned her. So I would only use this if the intermediary tasks will be short lived. Otherwise allow the task to be assigned at the team level.

Another variation is using the Last User in lane assignment to flow from the first Task to claim and open the second Task automatically; in this circumstance, the second Task must be in the same swimlane.

Directly Assigned Users

Another oft-requested assignment pattern is when businesses require a "user-driven" option to select and assign users. Figure 6. shows this scenario where Task 1 will decide who will be assigned Task 2.

Figure 6 The user in the first Task determines the user assigned the second Task

We will create an example of this scenario where the requestor chooses their approver.

Step 1: Build a team structure

When a user selects the assignee for the following task, they can only select members of the Team assigned to the swimlane. By leveraging Team structures, we can

• Ensure that the assigned user is authorized to complete the Task; and
• Allow for Team Manager reassignment if required

Figure 7 shows the Team structure used in the assignment examples.

Figure 7 Example Approvers Team Structure

Rely on Team structures for determining the users that can be assigned a task. If there are other data influences from different data sources you should ultimately validate the list by ensuring the users exist in the Team structure.

Step 2: Build A Select List Service

Here we will build a service to get the users who can be assigned and invoke it from the first user task. In this case, let's get the users from the Approvers Team.

Figure 8 Service Flow Definition

Code Snippet 1 Get Team Users List

By using the tw.local.teamName and tw.local.teamUsers it just makes it clearer the coders expectations, and makes the code easier to  understand compared to only using the non descript ANY types.

• Should the name list come from an alternative data source such as a database, be sure to embed a code loop that validates the source data against valid team members.
• The code needs to be robust and handle errors or failure to retrieve data, for example, when the lookup failed to get any users and checking that people cannot assign themselves as approvers for their work. Consider what the business needs want to do, such as will there be defaults or error handling.

Now we will add the select list in a user's view to assign the user. For this example, we created a simple coach view for the business object RequestData.

Figure 9 Request Data View

1. The Request Data business object
2. The configuration option sets the name of the Team.
3. The requestor is a single select list mapped to the service detailed earlier. Figure 10 shows this configuration.

Figure 10 Single Select Configuration

Step 3 Apply Direct Assignment pattern to Assign User

We then pass the RequestData business object as an output to the process and use the Direct Assignment pattern.

A detailed step by step guide of the Direct assignment pattern can be found here.

I would recommend that you extend the direct assignment pattern to again validate that the passed in user is indeed a member of the original team. Do not allow security roles to be circumvented by accidentlly assigning someone not in the role.

Figure 11 shows the process with the timer and assigned tasks added to the flow.

Figure 11 Manual User assignment with Direct Assign pattern

A variation of this would be where the user could select multiple users; in this case, in such a case, you could leverage a team filter to limit the assignees. As a recommended practice, do not filter teams to one as the task claimant, and the manager cannot easily reassign using the OOTB dashboards.

Also recommended for scripts on working with Teams is the 3 part blog by Gabriel Dermler, Gerhard Pfau, and Helen O’Shea

Part 1: Modeling teams with IBM Process Designer, Part 2: Developing services for dynamic team resolution, Part 3: Managing teams

Data Influenced Assignments

The next item discussed examines how different ways that process data can influence assignments. Data influenced assignments are a common process design requirement. Commonly data-influenced assignments are completed using a combination of decisions, services, and team filters. When discussing the types of influencers, they are usually data linked to the "Client" persona or based on data points that may be significant in the context of a process; examples might include

• Geographic location includes when specific approvers must process an Account opening in a bank within a branch. Or a commercial lending process must be processed by lending experts from the same geographical region as the lender's address.
• A relationship status such as tiers of the customer, for example, standard, silver, and gold customers can influence who will be assigned the process.
• Amounts or key data points, like in a purchase order process, the total cost on a purchase order. Or the sum borrowed in a lending process.

Often more than one such data may need to be considered. Decision tables can be helpful for assignments when multiple data points are required.

Reflecting on the direct assignment above, if we were to filter the assignment user list based on east and west via an earlier selection, this would modify the list of users that might be assigned. We shall now examine a few ways to address these assignment requirements.

1. Direct Assignment Variation

Earlier in this article, we discussed a standard assignment model called a direct assignment. In this variation, we consider the user wanting to limit assigned based on east or west users from the defined group structure detailed in figure 7. In this example, the select list becomes the focus of the data filtering, and the assignment model is unchanged. As with the earlier design, we have a select list and have now added two radio buttons that, when selected, trigger a reload of the user's list by sending the group name parameter into the list service.

Figure 12 Filtered By Just Members of the approvers-west-grp

Code Snippet 2 Get Team Users List with Role FIlters

We use the On selected event to trigger the reloadServiceItems on the select list.

Figure 13 Shows the reload on selected events

2. Assignment Data Filtering Variation

We will continue using the east-west data assignment preference as described above. Still, unlike in a direct assignment model, the data will be passed into a data filter service, creating a dynamic team to return to the team structure.

There is a lot of flexibility in what you can do in programmed filters. I would recommend that you consider the following
1. Try to ensure that the team integrity of the swim lane is maintainted when the team is filtered
2. Beaware that filtered lists of 1 will limit the dashboards and a users abiltiy to use out of the box reassigns
3. Discuss with the business if there is a possiblity that filtering will reduce the possible team size 0 this needs to be handled and ultimately must not occure that the filtered team is empty.

In this simple scenario, we input data directly into the assignment filter. Again the team name we are deriving from the user input on the request, but in the broader sense of data-based filtering, this might be part of a personas data or part of the collected process data or derived in some other way before the Task.

Figure 14 Team filtering driven by data passed to the Team FIlter

1. In the create request, we are explicitly allowing the user to choose east or west or no filter; this sets up the teamName as an output
2. The teamName is passed into the team filter and will allow for customization of the filtered Team
3. Shows the team filter settings and input parameters that will influence the assignment
4. In the debug view, we see the user selected the west user's Group
5. The instance Id helps to customize the dynamic team name
6. It shows how the team is dynamically named approvers-west-grp5404, matching the data highlighted in steps 4 and 5.

Code Snippet 3 Team Filter filters Original users and Limits the Team to groups based on the team name Data.

The filter is similar to earlier. The important takeaway is how the data is passed into the filter and used to alter the assigned users.

3. Assignment Data Routing Variation

In data point variation, the data drives a decision that influences the team assignments. While this can result in more swimlanes in your process design, it explicitly shows possible outcomes. Based on the decision outcome, the assignment is clear and results in less code, moving us closer to a low code process design. This reduction in code and the explicit nature of the process design make this worthy of consideration.

Figure 15 Data decisions determine the routing and, ultimately, the assignment.

1. The decision service could be a simple decision gateway or an advanced decision service applying business rules or decision tables.
2. The assignment is decided based on the data decision, so no further filtering or scripting is needed.

This simple execution model is easy for businesses analysts to understand. It is very explicit. And while there is an additional swimlane, the user interfaces and coaches can be reused.

Figure 16 Further highlights A simple decision works

In this decision case, the user's selection of east or west drives a decision on which Team will approve the request. But decision gateways can be replaced by advanced decision services, either built-in BAW or externally deployed in a decision manager.IBM

Conclusion

Assignment customizations and the chosen methods can influence the code understandability of a process. Seek to use the simplest assignment model you can. But know that when needed advanced assignment models are well catered for and possible.

Next, in this series, we shall look at the Priorities and Work schedule implementations.