SLA not working
There are a few configurations that need to be checked
1. Account/Site
- Check the request Account & Site,
- Now, go to Admin>Service Level Agreements>Filter the Account & Site and make sure the SLA is created for the same
2. Operational Hours
- Go to Admin>Service Level Agreements>Filter the Account & Site>Edit the SLA and check the below configuration
- If the above option is unchecked, then the request does not calculate the non-operational hours and Holidays
- You can check the Operational Hours & Holidays for the Account & Site under Admin
The below points affect the SLA
1. Holidays & Operational Hours
Go to Admin>Service Level Agreements>Filter the Account & Site>Edit the SLA and check the below configuration
If this option is unchecked, then SLA is calculated only during operational hours. Kindly note the Account & Site the request is created, then go to Admin>Operational Hours and Admin>Holidays and refer the configuration.
2. Ticket Status
The timer of the ticket will be paused when a status with timer "Stop" is assigned.
For example,
- A request is created at 9 am
- Set "On Hold" status at 10 am
- Set to "Open" at 11 am
- Closed at 12 am.
Even though the ticket is opened and closed in 3 hours, only 2 hours will be calculated for SLA, since the ticket was "On Hold" from 10 am to 11 am.
Under Admin>Status>Refer the configuration of the status.
Once the above configurations are checked, create a test request with the SLA criteria, post request creation check the Due By Time field to know if the SLA is triggered as configured.
If the SLA time is passed, check the history Tab of the request to if the SLA violation is flagged.
New to ADSelfService Plus?
Related Articles
How to send SLA notification mail to the different users when a SLA is breached for builds 10500 and above
We can use the Email feature in the custom triggers to send notifications to different roles configured in SDP-MSP. By default, the SLA notification can be sent to Account Managers, Point of Contact, Technician, Requester. If you would like to send ...To make SLA mandatory while creating a service request
The steps mentioned below make the SLA selection mandatory for any service request creation. Tested in builds : 14000 and 14301. Script: if(!jQuery("#servicesla-selected").attr("data-association-id") || ...Query to know SLAs configured and its details (MSSQL & PGSQL)
Tested in Build PGSQL (14300) or MSSQL (14306) PGSQL: select slad.slaname "SLA NAME", sdo.name "SITE", ad.org_name "ACCOUNT", slad.duebydays || ' Days,' || slad.duebyhours || ' Hours,' || slad.duebyminutes || ' Mins' "Resolved Within", ...SLA details
This report is used to get the complete list of SLA configured in the application. PGSQL SELECT sdo.name "Site Name" , sla.slaname "SLA", MAX(sla.duebydays) "SLA Days", MAX(sla.duebyhours) "SLA Hours", MAX(sla.duebyminutes) "SLA Minutes" , ...Send escalation email to the Technician "Reporting to" if SLA is violated (Deluge).
From Builds 10600 and above Follow the below steps and based on the update we need to create a custom trigger based on the action set under the SLA escalation notification and then with the help of that we can execute the custom trigger and the ...