About Escalation Rules

Information

Your system can automatically escalate and take action in issues that remain open or idle for too long through Escalation Rules. Escalation Rules help ensure Assignees and Submitters never neglect or abandon their issues, especially when they are used in conjunction with the Substatus Rules and Email Notifications configuration options.

There is no limit to the number of Escalation Rules you can create. Each of these Rules may have several parts to it, including:

  • Time Interval— Days, Hours and/or Minutes from Submit or Last Activity
  • Conditions— other criteria that must be met, such as:
    • Priority
    • Substatus
    • System Clock Status (Paused, Not Paused)
    • Issue Type
    • Subtype (1 through 4)
    • Organization
    • Department
    • Location
    • Project
    • Number of previous escalations
    • Assignment Status (Assigned, Not Assigned)
    • Assigned To
    • Target Date passing
    • Required By Date passing
  • Actions— other system-generated events that occur along with escalation, such as:
    • Updating the Assigned To
    • Updating the Priority
    • Updating the Substatus
    • Adding a (Public or Private) Note
    • Distributing (additional) Email Notifications
    • Closing the issue
  • Process Order— the Rule’s place among other Rules in the processing queue

In addition to Time Interval, the rate at which Escalations occur is also based on your SQL Server Escalations Job. Escalation can never occur at an interval greater than the current Job rate. For example, the Escalations Job is generally set during installation to a default rate of every 15 minutes. If you define a Rule with a Time Interval of 5 minutes , you will need to increase the Job rate to at least every 5 minutes or this Rule will still only be processed at 15 minute intervals.

Keep in mind, the rate at which any Email Notifications are sent is based on your SQL Server Outgoing Email Job.

On Premises customers may update SQL job intervals at any time, or re-create those jobs using steps documented in the Issuetrak Support KB. For cloud customers, the timing of the Jobs is based on the tier purchased.

Every time the Escalations Job runs, it will process all Rules, starting with your Process Order = 1 Rule. This means an issue may escalate many times during its life cycle, based on the same Rule and/or different Rules that apply as its values change. However, the issue will only escalate against one rule each time the Job runs, so the first rule that applies based on process order.

To minimize redundancy, try to use Conditions whenever possible and Actions that change at least one Conditional value so most Rules never apply more than once.

Example:

Rule A states:

IF (Time Interval) = “2 Hours” after “Time Submitted”

THEN ESCALATE

AND (Actions) Send Notification To = “Stan Sitwell”

ANY issues that stay open for longer than 2 hours after Submit will be escalated by this rule. As long as these issues remain open—the same Rule will continue to apply every time the Job runs. Each time, Stan (and any Email Distribution List Members with notify On Escalate ) will also be sent another notification.

Rule B states:

IF (Time Interval) = “5 Days” after “Last Activity”

AND (Conditions) Issue Type = “Service” AND Subtype 1 = “Request” AND Substatus = “Pending User Response-1st Attempt”

THEN ESCALATE

AND (Actions) Add Note = “We have not heard back from you on this service request. Please let us know what day and time we can perform your service.” AND Set Substatus To = “Pending User Response-2nd Attempt”

ONLY issues that stay open for longer than 5 days without any activity that also have this particular Issue Type, Subtype and Substatus will be escalated by this rule. As long as these issues remain open and their Substatus does not change back to Pending User Response-1st Attempt — the same Rule will not apply again. The Submitter will not receive this particular “friendly reminder” again.

In addition, consider your Process Orders carefully. If Rules have similar criteria and may ever be applicable at the same time—BUT one of those Rules changes a conditional value so the other Rules no longer apply—that Rule should be processed before any other Rules with similar criteria. For example, Issue #12345 is currently a High Priority issue that has had no activity for almost 4 hours…

Rule X states:

IF “2 hours” after “Last Activity”

AND Priority = “High”

THEN ESCALATE

AND Send Notification To = “Steve Anderson”

… Process Order = 17

Each time the Escalations Job has run since the 2 hours after last activity mark, this rule has continually escalated Issue #12345 and notified Steve.

Rule Y states:

IF “4 hours” after “Last Activity”

AND Priority = “High”

THEN ESCALATE

AND Update Priority To = “Critical” AND Update Assigned To = “Michael Bluth” AND Send Notification To = “Steve Anderson”

…Process Order = 16

When the Escalations Job runs at the 4 hours after last activity mark, this rule will make any further Escalations of Issue #12345 by Rule X obsolete. So Rule Y has been placed before Rule X in the processing queue using their Process Orders.

All users can view Escalation-related data in issues and reports.


Applies To:

Issuetrak 9.9+