IBM BPM, V8.0.1, All platforms > Get started with IBM BPM > Key concepts > BPEL processes and human tasks > Human tasks overview

Follow-on tasks

Follow-on tasks support people when they want to delegate parts of their assigned work to other people, and the control over the completion of the work.

Follow-on tasks can be created from stand-alone task templates that are stored in the Business Process Choreographer database, from task templates created at run time, or by providing a new task model at run time. You can start a follow-on task from a to-do task or a collaboration task that has the supportsFollowOnTask attribute set to true. A follow-on task can have follow-on tasks of its own resulting in a chain of tasks.

The input message type of a follow-on task can be different from its predecessor task. If the input message type of the follow-on task is the same as that of the predecessor task, the input message content of the predecessor task is passed automatically to the follow-on task. The message content can be overwritten when the follow-on task is created or started.

For a chain of follow-on tasks, the output and fault message types of each of the follow-on tasks must be identical to those of the first task in the chain, because the last follow-on task in the chain returns the message to the calling component or person (originator). The output or fault message content of the parent task is always copied to the output or fault message of the follow-on task. These messages can be modified in the follow-on task and the changes are copied to the parent task.


Authorization considerations

Follow-on tasks inherit the authorization roles from the predecessor task.


Lifecycle considerations

When the follow-on task is started, the predecessor task enters the forwarded state. A chain of follow-on tasks is handled as though it were a single task. This means that you can perform some lifecycle operations on any task in the chain and the correct behavior is applied.

For example:

Some lifecycle operations on a follow-on task can conflict with the lifecycle operations of the predecessor task, and are therefore not allowed. These are mainly operations that influence the end of the lifecycle of a follow-on task and need coordination with the predecessor task. The following operations can be performed on follow-on tasks:


Example: Follow-on tasks

The following figure shows a publishing process with a follow-on task for the human task activity.

In an article publishing process, the "Review Article" task is claimed by John. He is empowered by the process to review and approve the legal aspects of articles as well. However, this article describes the collaboration with a competitor product, and is thus very sensitive from a legal point-of-view. He reviews the informational aspects of the article, and decides to pass the article on to Sarah from the legal department for additional review. He creates a "Legal Review" task, with a description that highlights his legal concerns. He includes the article as input to the task, and then assigns it to Sarah. He then starts the new task as a follow-on task of his own "Review Article" task. His task enters the forwarded state, and the work on it ends. The process waits for the response from the invoked "Review Article" task.

Sarah claims her "Legal Review" follow-on task and starts reviewing the legal aspects. She makes some comments, and completes her task. The output message of the follow-on task is passed to the BPEL process. The article publishing process continues with the output that it associates with the "Review Article" task, but that comes from the "Legal Review" follow-on task. Because the "Review Article" task is an inline human task, it is deleted with the "Legal Review" task when the BPEL process instance is deleted.

Human tasks overview