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

Escalations

An escalation is an alert that is raised automatically when a human task is not actioned in the specified amount of time.

For example, if tasks are not claimed or are not completed within a defined time limit. You can specify one, or more, escalations for a task. These escalations can be started either in parallel, or as a chain of escalations.

You can define escalations for any task during modeling or, dynamically, when you create a task at run time.

Escalations are activated at a certain task state. The task will normally only be escalated because the expected task state has not been reached when the time limit for the escalation expires. However, it can also be triggered manually any time before the time limit expires by a user who has the appropriate authority. The time limit for the escalation is interpreted by the calendar that is specified for the task. You can specify multiple escalations (or escalations chains) that have the same activation state. An escalated task is put into the escalated substate.

You can define escalations that are activated when the task reaches the following task states:

Ready

For tasks in the ready state, you can define escalations for the following situations:

• Escalate when the task is not claimed in time using the expected task state of claimed.
• Escalate when the task is not completed in time using the expected task state of ended.

Claimed

To define an escalation for a to-do task or a collaboration task that is in the claimed state when the task is not completed in time, you must specify that the expected task state is ended.

Running

To define an escalation for an invocation task that is in the running state when the invoked service does not return in time, you must specify that the expected task state is ended.

If a task that is in the running state has an escalation defined for it, authorized users can trigger the escalation manually before the defined time limit expires.

Subtask started

For to-do tasks or collaboration tasks, you can define an escalation that starts when the first subtask is started. This state can be used for tasks with single ownership, but is mostly used for tasks with parallel ownership. For these tasks, the expected end state must be ended.

You can define repeating escalations. These escalations check the same expected task state at every timeout, and perform the defined escalation action until the expected task state is reached.

When an escalation is raised, the people affected by the escalation (the escalation receivers) receive work items. Depending on the definition of the escalation, the escalation receivers might also receive an email notifying them that the task is escalated. The list of users to be notified is defined by a people query. This query must resolve to a set of individual user IDs.

You can define the escalation in the task model so that the priority of the task is automatically increased either for the first iteration only, or for every iteration of the escalation. In the administrative console, you can specify how you define priorities in your organization, by setting values for the Task.Priority.Highest and the Task.Priority.Lowest custom properties for Human Task Manager.

For example, in your organization, you might use 0 to indicate the highest priority, other organizations might use 5 to express this priority.

Lifecycle of an escalation

The following diagram shows the state transitions that can occur during the lifecycle of an escalation.

• When a task is created, any predefined escalations are created and are put into the inactive state.

• When the task reaches the activation state for the escalation, the escalation is put into the waiting state and the timer is started.

• A waiting escalation becomes escalated, the escalation action is performed, and the associated task is put into the escalated substate if one of the following occurs:

  • The task has not yet reached the expected state and an authorized user triggers the escalation manually.

  • The task has not yet reached the expected state and the timeout is triggered.

• A waiting escalation becomes superfluous, and is deleted if one of the following occurs:

  • The task has reached the expected state and an authorized user triggers the escalation manually.

  • The task has reached the expected state and the timeout is triggered.

  • The task has reached an end state and the escalation is canceled.

• You can change the escalation duration and repetition duration.

The escalation action can be performed repeatedly.

Chained escalations

A chain of escalations is a series of escalations with the same activation state and expected end state of the task. These escalations are processed sequentially so that only one escalation is waiting at any one time. A chain of escalations is activated when the task reaches the activation state for the first escalation in the chain. In a chain only one escalation is active at a time, except for repeated escalations because they remain active. Escalations that are defined as a sequence are processed sequentially: when the first escalation is raised, the next escalation in the chain is activated, and so on.

The wait duration of a chained escalation is calculated relative to the timeout of the previous escalation, and not relative to the time when the task reached the escalation activation state. Thus, if the wait duration of the first escalation in a chain is two hours and that of the second escalation in the chain is three hours, the first timeout occurs two hours after the task reaches the activation state and the second timeout occurs three hours later, so, five hours after the task reached the activation state. This behavior ensures that a later escalation in the chain does not time out before its predecessors.

Dynamic durations for escalations

For some escalations, you might want to set the escalation period dynamically at run time. You can do this by specifying a replacement expression instead of the fixed value when you define the escalation. The duration variable must be enclosed in percentage signs (%).

The variable can be any of the following:

• A task variable, such as %htm:input.myEscalationDurationValue%

• A custom property, such as %htm:task.property.myEscalationDurationValue%

• For inline tasks, a process variable, such as %wf:variable.myVariable\myPart\myEscalationDurationValue%

Verify that the context data that you access is available when the escalation is evaluated. If the variable resolution fails, the duration is not set correctly. A CWTKE0038E error appears in the SystemOut.log file and your escalation is not set up.

The following table shows when escalation durations are evaluated:

Duration for	Is evaluated when	Context date must be set before the task reaches the following state:
Escalation	The task reaches the activation state of the escalation. For chained escalations, the duration of each escalation is evaluated when it is started.	The task activation state of the escalation.
Escalation repetition	The escalation is raised.	Escalated

Human tasks overview

Related concepts:
Changes to the timing of an escalation at run time
Replacement variables in human tasks
Replacement expressions and context variables in Integration Designer

Related tasks:
Create notification event handlers
Create an escalation for your human task in Integration Designer
Customize an email notification in Integration Designer

Related reference:
Human Task editor Duration tab