Escalation Management: Service Level Agreements (SLA)

Watch a video on the escalation management here.

Escalation management is widely used for IT service management, and is also part of the ITIL recommendations. Carefully created escalation processes can ensure that unresolved problems don't linger and issues are promptly addressed. Escalation criteria such as missed deadlines are defined and result in appropriate actions, such as a change of status or a notification to a project member. codeBeamer can send notifications and take automatic action (via the Tracker workflow) whenever users (via the GUI) and clients (via the remote API) submit and modify issues, or certain events or times are reached.

Using Escalation, Trackers can be configured so that issues that meet user-defined escalation criteria, that is issues that need extra attention, can be automatically flagged, so that they can become more visible in a timely fashion. The escalation trigger conditions and resulting actions are user-defined.

The examples in this chapter are based on the default codeBeamer roles, fields, workflow and working time, and an idealized scenario, where issues are submitted before their intended start (and end) date and the intended end date is at least the number of estimated hours (of working time) after the scheduled start date, but you can also use custom roles, fields, workflows and working time with the Escalation Management.

For more information, see:

• Trackers
• State Transitions
• Creating and Customizing Trackers
• Basics: Projects, Roles, Groups, Members and Users

Figure: Escalation Schematic Overview Diagram
You must login to see this link. Register now, if you have no user account yet.

Configuration

You can configure the Escalation Management rules for a Tracker via Tracker→Customize→Escalation:

Figure: Tracker Customize Escalation: no Escalation Yet

Escalation groups, processes and schedules are user-defined:

• Which tracker items (issues) are subject of escalation,
• The escalation schedule to apply to these issues,
• The actions to execute upon a specific escalation level.

Figure: Escalation Customize Detail

An escalation group is identified by a predicate, which defines which items or issues belonging to this group. The predicate appears as a Public Tracker View and is an issue or item filter which selects the escalation group.

Typically a predicate/filter will be based on the issue status, but you are not restricted to that and can include arbitrary issue attribute criteria in a predicate/filter, e.g. to have different escalation schedules for critical and non-critical issues (by priority, severity, etc.), or to distinguish between issues that have already been assigned and those that are not assigned yet.

Any combination of criteria is possible.

Ideally, escalation group predicates should be mutually exclusive, but there may be situations where an issue participates in multiple escalation schemes at the same time.

Examples

Example 1: Send Notification One Hour after Issue Submission

To arrange for a notification email to be sent one hour after an issue has been submitted, you can define the following 'predicate' (issue filter), and select the notification recipients. The escalation rule to be applied would be: "New issues must be verified within 1 hour after submission, otherwise automatically execute a state transition to Status “Unconfirmed” and send an alert to the Project Admin(s) via email." First, create a predicate for “New issues”, by clicking the view context menu selector in the right side of the header in the tracker item list page, and selecting "New View" menupoint. The selected Status is unset or “New”.

Figure: Tracker Bug New View

Figure: Escalation Schematic of New Issue VerificationYou must login to see this link. Register now, if you have no user account yet.

You should go back to the tracker Configuration page to set the escalation rules of this tracker view, click "Add" on the Escalation tab.

Figure: Add new escalation rules to tracker view, Example 1

Figure: Escalation Form Example 1, Verification

You could also choose to alert the users assigned to or supervising the issue, but they will automatically receive a notification about the state transition to “Unconfirmed”, so this is not necessary here.

If no state transition is associated with an escalation level, you should always consider notifying the assignees and supervisors.

Via the “Only to Members” checkbox, you can further control whether only direct project members receive the notification/alert mails, or also indirect members (members of groups linked to project roles).

The offset of the escalation due date from the issue anchor date need not necessarily be a constant value as in our example (1 hour after Submitted at).

You can also define the offset via a formula or expression in the Limit field (using the same syntax as described in the Computed Tracker Item section, above).

For example: To define, that high and highest priority issues must be verified within 1 hour, others within 4 hours, you could define the Limit as: (priority == 1 or priority == 2) ? 1 : 4

If you do not specify a Limit/Offset, the offset will be implicitly 0, so the escalation date is the same as the anchor date. If you do not specify a Limit/Offset Unit, the offset will be implicitly in hours.

If not only the escalation Limit, but also other escalation settings (number of escalation levels, actions, etc.) depend on issue attributes, you must define multiple escalation groups and include the criteria in the group predicate.

Example 2: Send a Notification upon Receipt of New High-Priority Issues

Select issues in the Tracker View for “New high priority issues”, where the Priority is “High” or “Highest” and the Status is unset or “New”.

Figure: Tracker Task Filter High Priority

If workflow is activated for the tracker, you can automatically update other issue attributes as well, e.g. assign the issue to users in a special role, increase the issue priority, etc., via Tracker→Customize→StateTransitions:

Figure: Tracker Customize Workflow Transitions

(if applicable) will be executed before the notification mail is sent, so any changes made by the workflow transition will be reflected in the notification mail

Figure: Workflow Transition Notification

Hint: If you want to define special escalation states and escalation workflow transitions, that should not be accessible to regular users, simply define the workflow transitions with no permissions granted. This will hide these transitions from all users, but the Escalation Management will still be able to execute them.

Example 3: Send Notification if Issue is Still Unconfirmed After 8 Hours

In this example, if the issue is not clarified within 8 hours of working time, send a reminder to the Submitter, Assignees and Supervisors.

Figure: Issue Clarification Escalation SchematicYou must login to see this link. Register now, if you have no user account yet.

We create a new escalation group “Unconfirmed issues” for this example (the predicate is straight forward and not shown here):

Figure: Escalation Group Unconfirmed Issues

This defines a one-shot reminder. We will show how to create a recurring reminder later.

Example 4: Open Issue Still Unassigned and Supposed to Start within 30 Minutes

Figure: Escalation Issue Assignment SchematicYou must login to see this link. Register now, if you have no user account yet.

The group predicate applies to issues with Status not Resolved or Closed and “Assigned to” unset:

Figure: Issue Assignment Form

The escalation rule is bound to/anchored at the field “Start Date”:

Figure: Escalation Rule and Start Date

The field “Start Date” differs from “Submitted at” used in the previous examples in two aspects:

• It is an optional field and may not contain a value.
• It is mutable and can be updated at any time.

If the anchor field of an escalation rule does not contain a value, the escalation rule is ignored for this issue.

If the value of an escalation anchor field changes, the escalation will be rescheduled.

If the rescheduled date is after the old escalation date, the escalation will fire (again) at the new/later date, even if it has already been fired before.

Example 5: Issue Is Not Started, and We Are Past "End Date" Minus "Estimated Hours", or Behind Schedule

Figure: Escalation Behind Schedule SchematicYou must login to see this link. Register now, if you have no user account yet.

The escalation group predicate should select issues with “Status” not {Resolved, Closed} and “Resolution” unset.

Figure: Tracker Task Filter Behind Schedule

The escalation rule is anchored at the field “End Date” and the offset is retrieved from the field “Estimated Hours”:

Figure: Escalation Rule Behind Schedule

Both fields involved here, “End Date” and “Estimated Hours” are optional and mutable.

If either field value changes, the escalation is rescheduled.

If no “End Date” is specified for an issue, this escalation will be ignored. If no “Estimated Hours” are specified, the escalation will be due at “End Date”.

Example 6: Recurring Escalation for Missed Deadlines

Figure: Escalation Alert Every 8 Hours SchematicYou must login to see this link. Register now, if you have no user account yet.

The escalation group predicate “Open issues” should select issues with “Status” not {Resolved, Closed}.

The escalation group defines two rules:

Figure: Escalation Rule for 8 Hour Interval Alerts

The first rule defines the initial escalation that must be bound to an issue field. The second rule defines the escalation repetition interval.

Limit and actions of initial escalation and repetitions can be different; the repetition Limit/Offset must be at least 60 seconds.

There can be only one “after last escalation” rule per escalation group, and this must be the last one and should not be the first or only rule.

Here is the resulting overview for all example escalation rules:

Figure: Overview of All Escalation Examples' Rules

These are only examples to demonstrate different aspects of escalation management. These examples are explicitly not a template/blueprint for rules to be used in production systems.

Issue Escalation Schedule

Figure: Issue Details Escalation Tab

The escalation schedule shows the history of fired escalations plus all pending scheduled escalations in chronological order.

The escalation schedule cannot be updated directly, but changes of the tracker escalation rules or the tracker item are reflected immediately.

To see the Escalations tab, a user must have “Issue – View Escalation Schedule” permission on the tracker. By default, this permission is only granted to the role “Project Admin”, but you can customize that via Tracker→Customize→Permissions:

Figure: Issue- View Escalation Schedule

Issue Reminder

You can set issue reminder by clicking on More menu - Add reminder option. Using this functionality a reminder email will be sent to the current user. After set the desired fire time on the overlay, the reminder will appear on the Escalation tab (as Reminder type Escalation Group).

Working Time Calendars

Working time is defined in Working Time Calendars.

There is one default system wide calendar (My Start →System Admin→System Calendar) and a specific calendar per project (Project→Admin→Calendar).

All project calendars are derived from the system calendar and should only define project specific deviations.

The basic work calendar definition consists of default business hours per day of the week.

Figure: Working Time Calendar

There can be multiple entries for the same day of the week to reflect historical or intentional changes.

For example: Generally we do not work on Saturday, but starting from Jul 1, 2009 until Dec 31, 2009, we also plan to work on Saturday morning from 9:00 to 12:00.

On top of this basic weekday pattern, deviations can be defined for specific dates (day/month/year) or for the same calendar day (day/month) in every year or a specific range of years From ... Until.

Figure: Working Calendar Special Days

Examples:

Jan 1, is a holiday (“New year”) in every year.

Dec 24 (“Christmas Eve”) and Dec 31 (“New Years Eve”) are not holidays, but if they default to workdays then work hours are from 9:00 – 13:00, as employees leave early.

Between 1954 and 1990 June 17 was a German federal holiday known as “German Unity Day” in Germany. After the German east-west reunification in 1991 this was changed to Oct 3.

Aug 02, 2009, although a Sunday, is an exceptional workday “Midsummer Madness Sale”.