IBM BPM, V8.0.1, All platforms > Authoring services in Integration Designer > Developing business processes > Building human tasks > Create an escalation for your human task

Escalations

An escalation is a course of action that is implemented when an expected result from a task has not been achieved within a set period of time.

You can use IBM Integration Designer to model escalations for tasks that are in the activation states of ready, running, claimed, or subtask.

A task in a ready state is escalated when it is not claimed in time, and a task in either a claimed or a subtask state is escalated when the work has not been completed within the required time limit.

For example, you can add an escalation to a work item so that when it has been unclaimed for too long an email is sent to a potential owner to urge them to claim it. Or, an escalation can be used to notify managers when a work item has stayed in a working state for too long. Or, you can model an escalation for a subtask to make sure that it gets completed in plenty of time for the owner to finish the associated parent task.

An escalation can result in any one of the following actions:

1. the creation of a work item for a set of users,
2. notification of an appropriate staff member via email,
3. notification using an event handler.

Designing an escalation

When you model an escalation to be created in the human task editor, you will need the following information to complete it:

• to whom the resulting work item should be assigned,
• the period of time before it should be escalated,
• the state that you want the task to be in when the escalation value times out (if it is not in this state, then an escalation is thrown),
• the action that should be taken in the case of an escalation,
• the mode of notification,
• whether the escalation should be performed again, and if so, how soon,
• whether the task priority should be increased during the escalation.

Lifecycle of an escalation

Here is a brief description of the stages that a typical escalation will go through.

1. An instance of a task is created and, if it has an associated escalation, it remains inactive until the task reaches the activation state.

2. When the task reaches the activation state, the first escalation of each chain is initialized with the starting of the Escalate timer, and the escalation moves to the waiting state.

3. When a timeout occurs, the system checks to see if the expected task state has been reached. If the task has reached or passed it, the escalation state is changed to superfluous. If the expected state has not yet been reached, the escalation state is changed to escalated, and the escalation action is invoked, and one of the three possible actions occur (work item, email notification, or event handler notification).

4. The escalation is repeated according to the Repeat notification every value.

5. The escalation's priority is increased according to the Increase task priority value. The priority can be increased repeatedly if an auto-repeat duration is set.

Chained escalations

A chain of escalations is a series of escalations with the same activation state that are processed sequentially so that only one is active at any one time. The wait duration for each of the escalations in a chain is cumulative. That is, the timer on the second escalation in a chain will not start until the first escalation has timed out. This prevents escalations that are further along in the chain from timing out before the ones at the beginning. Also, keep in mind that an escalation with an expected state of end, cannot precede another escalation. Such a situation would never escalate, and you will receive a validation error if one exists in your diagram.

Parallel escalations

Parallel escalations are two or more escalations that are processed at the same time as opposed to sequentially. Each of the escalations has the same activation state but, in contrast to a chained escalation, its wait duration fires independently, and any one of them can have an end state as the expected state.

Escalations and task ownership

You have two choices of ownership pattern for your human tasks: single or parallel. One consequence of the choice of single or parallel ownership is in the handling of escalations. For single ownership you can define escalations that are triggered when the task is in the ready or claimed state. Such escalations are not applicable to a parallel ownership task.

If you change the ownership of a task from single to parallel, you will be prompted for what to do with escalations that you have defined for the ready or claimed states. You can use them in a modified form, or you can delete them. See the related topic on Ownership Patterns for more details.

Example

To see an example of a human task escalation that you can build and run yourself, go to http://publib.boulder.ibm.com/bpcsamp/index.html, and click Samples for v7.0 > Human Task features > Escalation.

Create an escalation for your human task

Building human tasks

Related concepts:
Ownership patterns

Related tasks:
Subtasks