Escalation Rule

SysAid Product Manager


Service Desk

Escalation Rules

New Escalation Rule

This page allows you to build or edit an escalation rule. The page is composed of three sections, which determine:



You can also name the escalation rule and choose if it's enabled or not. An escalation rule which is not enabled does not run.


Make sure to click Save rule at the bottom of the page when you are finished.



Which service records are escalated?


The top section of the page allows you to determine the exact scenario in which an SR is escalated. The escalation rule only affects SRs that meet all of the requirements you specify here. Using the drop-down menus and the query builder, you make the criteria as granular as you like in determining exactly which SRs are affected.


 This escalation rule affects all active incidents with a priority set to "Highest" and

 assigned to the "IT G" admin group, and have never been reopened


When are the service records escalated?


After having determined which service records to escalate, you must then determine when they will escalate.

Escalation rules are triggered within a five minute (On-Premises) or ten minute (Cloud) window of the time you specify here.

When the number of hours you enter is 167 or lower, SysAid calculates the hours according to the operating times of the SR's request user. When the number of
hours is 168 or higher, SysAid calculates the hours in absolute time - not business hours.

You have three choices:


  1. X hours/minutes after a specific time. The drop-down list includes a selection of date fields from the SR form.
  2. X hours/minutes before a specific time. The drop-down list includes a selection of date fields from the SR form.
  3. After X amount of time has passed on a particular timer. The drop-down list includes all timers you've configured under Settings > Service Desk > Timers.



Alternatively you can use the Mode drop-down to set escalation rules to trigger every time a ticket is updated or when a ticket is created.





What happens when the service records escalate?


When an escalation rule escalates an SR, you can set any number of things to occur. You can:

  • Send out a notification, either by email, SMS, or both: Choose who receives the notification using the check boxes for predefined options, or enter a specific user or admin in the Notify. An Administrator's direct manager is configured on the edit administrator page under User Management.

    Refer to Customized Notifications for a full list of tags you can use in your emails.

    To send notifications to individuals based on escalation rules that run on workflow action items they are associated with, using the Notify the following user(s) check box. For more details, see the Run Escalation Rules on Workflow Action Items page.

  • Reassign the service record: Click to open a list of all admins.
  • Change the status of the service record
  • Change the priority of the service record
  • Choose an escalation level: Each time an escalation rule runs on a service record, the rule sets an escalation level for that service record. An escalation level serves as an upper limit used by other escalation rules to determine if they should run on the SR.

    For example: an SR was escalated by an escalation rule that sets the SR's escalation
    level field to 10. If an escalation rule set to level 5 contains criteria that would later be applicable to the SR, it would still not run as the SR has been escalated beyond the rule's upper limit. An escalation rule set to level 15, however, could still run on that SR.

    If you choose the option "Do not escalate," the escalation level of the SR is reset to zero, and all of the relevant escalation rules continue to run on the SR until the SR is modified in a way that no longer meets the escalation rules' criteria. Be very careful if you use this option, especially if the escalation rule is designed to send out emails.

  • Use the action builder to affect almost any change you would like

The action builder allows you to change any field on a service record at the time that it escalates.


To set a new action for the escalation rule

  1. Click Action Builder.
  2. Choose the field(s) you would like to change.
  3. Enter the new value for the field.
  4. Click Create Filter.

Notice that unlike other places the Expression Builder appears, this time you can only select the And statement. All actions you specify are carried out at the time the escalation rule runs. Any data that was previously in the field is overwritten.


 This escalation rule emails the three parties indicated by the check boxes, as well as Julie,

 who appears in the "Notify" field. It changes the priority of the service record to Very High,

 and changes the admin group to "Support." The escalation level is set to 15.

SysAid Wiz
Note that EL Levels work the opposite way as described. An ER with an EL Level of 10 will run on an SR with an EL level of 5. So it works in Ascending order currently.
I like the escalation rule as a good way to change status of service requests under specified circumstances, but although the Action Builder allows me to define new values for any other field, these changes are not being applied when the rule is activated. eg the status will change but the category will not despite being told to do so by the Action Builder.

Any ideas??
The escalation rules are not working as should nor am i getting a notification advising of an escatalation

Scenario 1,

I have a few escalation rules that determines when the priority changes which is observed, however I do not receive an email advising of the change.

Escalation #1 : Escalates service records with status Open, with priority Critical. Triggers on 2 hours 1 minutes after DueTime. Notifies: Administrator, Administrator's direct manager.

Escalation #2 : Escalates service records with status Open, with priority High. Triggers on 4 hours 1 minutes after DueTime. Notifies: Administrator, Administrator's direct manager. Change priority to Critical.

Escalation #3 : Escalates service records with status Open, with priority Medium. Triggers on 12 hours 1 minutes after DueTime. Notifies: Administrator, Administrator's direct manager. Change priority to High.

Escalation #4 : Escalates service records with status Open, with priority Low. Triggers on 24 hours 1 minutes after DueTime. Notifies: Administrator, Administrator's direct manager. Change priority to Medium.

Scenario 2
The following scenario highlights Escalation Rules created to send notification based on a custom field added to an Incident Ticket. Each time the custom field option is yes, the system should notify a group of persons. This is not being done.

Escalation #1 : Escalates service records with type Incident, with status Open, Major Incident = YES Triggers on 0 hours 1 minutes after ModifyTime. Notifies: Constance Vassell,Justin Taylor,Marsha Bailey,Shane Brown, Administrator. Change priority to High.

Can someone please provide feedback as to what i need to do or is doing wrong.

Former Community Manager
Hi Marsha,

Do you mind posting a screenshot of one of your escalation rules so we can look for issues that could be the reason why they're not firing?


How to write an escalation rule, which will send everyday once reminder notifications to individual assignees in case for open tickets.
Former Community Manager
Hi saurabh,

During my time as an incident manager, I wanted to do something similar to notify admins. Ultimately, I found people started to ignore the emails and it was ineffective. You may want to consider scheduling a regular report to go to a management distribution list. Such a report would show managers, not just the IT admins, how their teams are performing and do it in a way that's publically visible to everyone. That tends to motivate managers to intervene more on aging tickets.

From an escalation rule perspective, the way I can think to do it would be to build the rule to run 24 hours after last update. Then, when the escalation runs, send the notification and add a note into the ticket, or somehow change the value so the last update time changes to the time of when the rule runs. Set the "Escalation Level" option to "Do not change" so the escalation rule would run again.

Be careful though - you don't want to create an endless loop of updates/notifications. I would test this out on a test environment first.


Thanks Michael for your prompt reply. I will try this.

Is there a way to have Escalation rules filter when the modify user is the Escalation Agent
Former Community Manager
Hi dchurcorb,

Out of box, there's not a good way to add the filter if the admin is the last person to modify the record.

Since escalation rules are designed for preventing service requests from just "sitting around," the idea is that they would run no matter who last modified it. I'm really curious to know the use case you're trying to solve - this could be a good idea for a feature request.


We are using it to escalate when a User is Responded, and when a Technician responded. The problem is that when the Escalation Rules Run, it changes the Modified by user the Escalation Agent. Then when the User Responded Escalation Runs, It switches back to user Responded because it see's that the last modified is not the technician. right now, I would have to include each user separately in the escalation rules, but that would be rather burdensome. The Idea is that when a ticket is modified, and the user is not one of our 5 admins and the user is not the escalation agent, then change the escalation to user responded. This then set the count down for 24 hours for alerts to our techs.

It would be nice to use both the Email Agent, and the Escalation Agent as selectable users in the modify user field.

I hope that this explains clearly when I am trying to accomplish.

Super SysAider
Question, if a workflow action is assigned to a non-administrator (ie. end user) and they sit on this action for x period of time, how would we create an escalation rule to notify the manager of the assigned to end user that they are not completing these actions in a timely manner?
SysAid Product Manager Community Manager
Hi Anthony,

Currently, SysAid doesn't support action item escalation rules, and there is an open feature request on this topic (#14776).

A viable workaround would be to create a special status such as "Action item waiting for end-user", and create an escalation rule based on this status, which will notify the assigned administrator (or others) of the whole workflow of the problem after x amount of time. There is no option to notify a variable end-user's manager.


This message was edited 1 time. Last update was at Jul. 15, 2015 09:28 AM

Hello -

I may be missing something, but I would like the option to De-escalate a ticket removed from our process. I can't seem to locate how to accomplish this. Can someone assist?

Thank you!
SysAid Product Manager Community Manager
Hi GinAdmin,

Can you please clarify what you are referring to? Please attach a screenshot if applicable.