Auto Flow

September 26, 2012 — Jim Volpe

A handy new feature in BPM 8 is to automatically flow to the next task. You can use it to automatically start the next task within an instance if it is assigned to the same person. There are several cases when this can be useful, here are a few that I will walk through:

• Avoid long wait times for system services
• Make distinct steps within a process more visible
• Assign a second activity to the same person, but only sometimes
• Wait for prerequisites, but flow otherwise

I will wrap up the post showing the routing options that are possible.

Avoiding Long Wait Times

In this example, the system lane activity takes a long time to complete. If the second coach does not depend on the results of the nested service, then the user is waiting unnecessarily.

To avoid having the user wait, we can split the activity into three (see diagram on the right). The first activity includes the first coach and is run in the human swim lane. Then a split allows the Send Document Request to run in a system lane without the user waiting for it.

To enable auto flow, check the “Automatically flow to next task” setting on the Prepare Document Request activity:

In doing so, we can have the task for Field Inspection sent seamlessly to the same person. Just set “Last User in Lane” for the assignment of the next activity in the swim lane; in this case, the Inspect Location activity. That’s it. When the task for Prepare Document Request completes, the user will see the next task start in their browser automatically.

Making Distinct Steps More Visible

Splitting the activities above into three is also an example of adding more visibility into the process. If you looked at the in-flight instance diagram for the original process, where there was only one activity that included both of the coaches, you would not be able to see how far along it was. With the service split into three, you can. Imagine a set of 5 steps that one person handles, each taking a few days each. Allowing visibility into which steps are complete could be valuable.

Sometimes Assigning a Second Activity

It is not unusual for users to play different roles in a process. In this example, anyone can run the Open Issue task as the Requestor, but the Analyst is assigned specifically. If the Analyst and the Requestor are the same person, then the second task can be run right away. If the Analyst is different than the requestor, then the Requestor will be done once Open Issue is complete.

No System Lane Activity Between

When I initially tried this scenario, I included a “Determine Analyst” activity in a system lane. This does not work for automatically flowing. The activity to automatically flow into must immediately follow the first. Solving this was simple enough. I just nested my Determine Analyst service inside the Open Issue service.

Wait for Prerequisites, Flow Otherwise

This pattern can be use when splitting flow to additional participants, including one who has a consolidation activity after they all complete. The Review Design activity is set to automatically flow. If the other two parallel activities, Analyze Manufacturability and Analyze Serviceability, complete before Review Design completes, then Review Design will auto flow right into Consolidate Results. The one caveat here is that users may expect Consolidate Results to always run as part of Review Design. Handling this expectation could be handled through training or documentation within the last coach in Review Design.

Routing Options

The activity that you would like to automatically flow to does not necessarily need to be assigned via Last User in Lane. Any assignment that assigns the task specifically to the same user (Last User in Lane, Custom) will work, even if the activity is in a different swim lane. Assigning to a group (Lane Participant, Routing Policy), even one that the person belongs to, does not work. Routing to a List of Users works, but only if the person is the only one in the list.