- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-10-2019 11:54 AM
We have a P1 incident response SLA that attaches when a P1 incident comes into the system. Once the incident is assigned, the SLA completes. Now when the assigned person looks more into the ticket htey find its really a P3 not a P1 and changes it. The P1 resolution SLA cancels as we would like because its in progress.. the P1 response stays as completed. How could i have it change to canceled? is there a rule or script we need to create that runs nightly to change any response slas where the priority doesn't match or something?
Solved! Go to Solution.
- Labels:
-
Performance Analytics
-
Reporting
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-10-2019 12:19 PM
Hi,
I believe that cancelling the SLA would be counter productive (and not particuarly ITIL aligned).
The SLA is\was valid at the time it was initiated and met IE the task was being treated as a P1 until someone decided it was not, and retrospectively cancelling the SLA effectively skews SLA deliverables\task management statistics.
Similarly if the SLA was not met and was breached before the task priority was downgraded a P1 SLA would still have been breached.
This SLA data is important as long term it allows for analysis of resourcing for P1 tasks and also analysis of task creation\triage issues.
If you must take this approach then I'd suggest a solution based on task after BR triggered when Priority changes as this would be a cleaner\easier solution than a daily scheduled job.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-10-2019 12:19 PM
Hi,
I believe that cancelling the SLA would be counter productive (and not particuarly ITIL aligned).
The SLA is\was valid at the time it was initiated and met IE the task was being treated as a P1 until someone decided it was not, and retrospectively cancelling the SLA effectively skews SLA deliverables\task management statistics.
Similarly if the SLA was not met and was breached before the task priority was downgraded a P1 SLA would still have been breached.
This SLA data is important as long term it allows for analysis of resourcing for P1 tasks and also analysis of task creation\triage issues.
If you must take this approach then I'd suggest a solution based on task after BR triggered when Priority changes as this would be a cleaner\easier solution than a daily scheduled job.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-31-2022 02:09 PM
P1s aside, there are valid reasons for cancelling a completed SLA. For example a CI being affected by change activity triggered incidents during the expected outage window. The SLAs complete, whether in or out of compliance but, they shouldn't count. They can be filtered form an SLA report based on the close code of the incident but, it leaves the ticket owner confused to see "completed" slas on the ticket.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-10-2019 12:30 PM
This is actually the answer i was hoping to get. This is what i have been trying to say but couldn't come up with a perfect way to say it. Thank you. My thoughts were that it was a P1 and if you didn't assign it until it failed, you didn't know it wasn't a P1 at the time. So i agree, it should stay. Now to convince the rest.