Last week I talked about how you know who the right participants are with regards to a particularly complex Task Assignment and Routing implementation. I also talked about how you assign tasks and route information to them. But I finished by explaining why to a Business Process Developer, trying to implement a Task Routing rule, such as the example I gave, is a nightmare because of a lack of clarity around how to access the data necessary to implement the rule.

From the Process Developer’s point of view, the “right” answer to solve a complex routing problem like this is to develop a custom Task Routing Service to determine the list of users who should be given the opportunity to complete the task. If the conditions for eligibility are very dynamic (if they could change in a few minutes) then it’s also a good idea to develop a related service that will tell you if a specific user is eligible to claim a specific task.

When a task is ready to be performed, invoke the first service to get all of the eligible users.

When a user claims the task, call the second service to determine if they are (still) eligible, and return the task to the pool if they aren’t.

Read the rest of this entry »

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.

Read the rest of this entry »

Recently, I was working with a client to implement a managed Loan Origination Process using Lombardi’s Teamworks BPM suite.

As with any real-world process, there were a few interesting “gotchas”, but on the whole it was a pretty standard process that many of you would easily recognize.

In this case, modeling the Loan Origination Process using BPMN diagrams was fairly straight-forward, but when we got to the point of implementing Task Assignment and Routing things got interesting. Let me very loosely paraphrase some roughly similar Task Routing requirements (that I made up for this blog entry):

Read the rest of this entry »