Getting Tasks to the Right Participants, Part 2

Last week, I outlined a loan origination process with a particularly complex Task Assignment and Routing implementation. Since Task Routing itself deals with the Process Participants, I left off with the question, How do you know who the right participants are and how do you assign tasks and route information to them?

All BPM suites have one form of task list or another that holds all of the tasks that are assigned to a user and all of the unassigned tasks that the user can claim. Sometimes the task list appears on some sort of a Portal. Sometimes the task list is integrated with a mail client like Microsoft Outlook. Often task notifications are emailed to users. Task Routing in a process is all about getting the right tasks to show up on the right user’s task list at the right time.

A BPMN swim lane indicates the Role (in the process) of the Participants who execute any of the Tasks in the lane. These BPMN Roles can be very specific, both at the process definition level and at the process instance level. For example, an individual who is acting as a Reviewer in one instance of a process may be acting as a Requestor in another instance of the same process.

In many processes, a single task may be routed to a group of people rather than assigned to a single user. Let’s refer to this group of users as the Task Group. All of the Task Group members are eligible to claim the task until one member of the group claims the task.

If you’ve dealt with Authorizing a User in a “normal” application, then Assigning a Task in a process will seem very familiar. When people log on to web-based applications there is almost always a two step process occurring under the covers: Authentication and Authorization.

Authentication is conceptually simple: Is the user who they say they are? This is usually handled by prompting for a user id and a password. If the two match, then the user is someone who can log on to the system. In Single Sign On environments, authentication is generally handled by a token (such as a SAML assertion ) that vouches for the user’s identity.

Authorizing a User is often a bit more involved than Authenticating a User: Is the user allowed to perform a specific task or view some specific information?

Authorization is less straight-forward than Authentication because a single application may be written to service users with significantly different permissions to perform tasks and to view information. If the logged on user has specific permissions, then they can perform specific features and view specific information. Conversely, if they don’t possess the proper permissions, then they cannot access some of the application’s features or view some of the information.

The relationship between Task Assignment and User Authorization is pretty obvious:

Authorization logic is applied to determine whether or not the logged on user can perform a task or view some information.

Task Assignment logic is applied to determine the group of users who are authorized to perform a task or view some information.

Many organizations use an LDAP repository like Active Directory to hold the Authorization information associated with users. In this model, users are assigned to specific groups and Authorization is fairly straight-forward. Assigning a BPMN swim-lane to users who are members of a specific LDAP group is a no-brainer.

Unfortunately, in the real world the membership of a Task Group can be very dynamic. Here is an example slightly modified from the loan origination process that I worked on:

The Task should be assigned to all Credit Officers with a Lending Authority Limit of more than $50,000 who have processed less than 5 applications this week.

At first glance, it seems reasonable to create an LDAP group for Credit Officers with Lending Authority over $50,000 — but it’s really not. The required Lending Authority Limit is actually based on the amount of the loan. You need a Credit Officer with authority greater than the amount of the loan, so this is really an attribute of the Credit Officer rather than a specific group that they belong to. The second half of this requirement, “who have processes less than 5 applications this week”, is an extremely dynamic categorization… There’s no way that you would store this sort of dynamically changing data in an LDAP repository.

To a Business Process Analyst, specifying a Task Routing rules like these are very straight-forward. To the Business Analyst, it’s extremely clear who should be eligible to claim the task, and who shouldn’t be able to claim the task.

To a Business Process Developer, trying to implement a Task Routing rule like this is a nightmare. It’s usually very unclear how to access the data necessary to implement this rule.

Ed.: Next week, in the final installment of this series, John will explain the “right” answer to solve a complex routing problem like — developing a custom Task Routing Service.

Questions? Let us know below in the comments!