Hello,
We have a big issue with SLA in SW, they are not working as intended and cannot be used in the way we want, let me explain that :
Our SLA are set like this :
([Incident] - [Low] - to resolved) within 50 hours.
([Incident] - [medium] - to resolved) within 16 hours.
([Incident] - [high] - to resolved) within 6 hours.
([Incident] - [critical] - to resolved) within 2 hours.
Each time a SLA "breach", the ticket is upgraded to the upper SLA : Low to Medium to High to Critical
This mean if you are not resolving a "Low" ticket in 50 hours, it will switch to Medium, then to High after 16 hours and so on....
But in SW when the Low "breach" is triggered, all the other SLA are automatically "breach", because breach times for every SLA’s are calculated from the incident's creation time rather than sequentially per SLA..
I've raised a ticket to the support to explain the situation but they told me this was totally intended :
Good Day!
We got an update from our engineers.
They have identified the issue that there is a problem with SLA time calculation when the initial SLA breach time is greater than the next SLA's breach time.
For example, the SLA rule 71689 has a breach time of 50 hours. Once it breaches, the next SLA rule 71690 gets applied and it has a breach time of only 16 hours. Since these falls within the previous SLA’s breach window, SLA violations occur almost immediately.
It appears that breach times for every SLA’s are calculated from the incident's creation time rather than sequentially per SLA.
To address this on your end, you will need to adjust your SLA settings, keeping in mind that the violation time is based on the created_at timestamp.
Our product team confirmed as well that this is working correctly per the current implementation. They mentioned that this will be addressed when we work on the timing mechanism in the system to better support SLAs restarting themselves and the ability for them to change based on the new attributes on a ticket.
For now, please apply the suggested work around which adjust your SLA settings based on the created_at timestamp.
Thank you and have a great day ahead!
And here is my answer :
- What’s the point of having the option to automatically change the priority when the SLA breaches, if all of them end up breaching once the switch happens?
- If I change my 16-hour SLA to 66 hours (50 + 16) in order to prevent the Medium SLA from breaching immediately, how do I manage incidents that start with a Medium SLA? Wouldn’t it then become a 66-hour SLA, which is higher than the original Low-priority SLA?
I don't really know where to go and what to do about that , you guys have the same issue ? ( and found a workaround you could share :) ) should i raise a feature request ?
Thanks for your help
