- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-06-2017 07:57 AM
The screenshots attached show our current SLA Definitions. We are experiencing inconsistencies, where with Incident Response we are seeing new values being created when no values have technically changed. We think the stop condition is misconfigured and causing the new values to be created.
I'm looking for ideas on how to best configure SLA Definitions and am interested and knowing what others are currently using.
Solved! Go to Solution.
- Labels:
-
Benchmarks
-
Incident Management
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-06-2017 09:26 AM
Hi Michael,
I responded last week on another thread about one common way to create an Incident Response SLA.
You stated: "...with Incident Response we are seeing new values being created when no values have technically changed."
I believe you mean you are getting new Incident Response records when it appears the applicable conditions (in other words, the Start/Stop/Reset conditions) are not being met. I would have to look at a particular example incident in your instance, the associated task_sla records, the SLA Definition, and the history, but I am going to make a quick guess here, based on an analysis I did for a different customer HI incident a week or two back.
Your Reset condition is: Assignment group is different From Previous Assignment Group.
My assumption is your Previous Assignment Group is a custom field and it is not being set as expected. It sounds like the Reset is evaluating to true when you don't expect it to happen. This would cause your existing Response SLA record to be set to Completed and a new Response SLA record to be started.
Based on your Reset condition, I suspect your Response SLA should not be started if the Assignment group is empty. And your Reset should only happen if the Assignment group changes, and my Incident Response SLA answer provides information on one way to set that up.
Regards,
Ed
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-06-2017 08:17 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-06-2017 08:29 AM
Hi Michael,
The foremost thing for an SLA to work as desired is the start, pause and stop condition.Also if you are using a custom schedule, please check the same.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-06-2017 09:26 AM
Hi Michael,
I responded last week on another thread about one common way to create an Incident Response SLA.
You stated: "...with Incident Response we are seeing new values being created when no values have technically changed."
I believe you mean you are getting new Incident Response records when it appears the applicable conditions (in other words, the Start/Stop/Reset conditions) are not being met. I would have to look at a particular example incident in your instance, the associated task_sla records, the SLA Definition, and the history, but I am going to make a quick guess here, based on an analysis I did for a different customer HI incident a week or two back.
Your Reset condition is: Assignment group is different From Previous Assignment Group.
My assumption is your Previous Assignment Group is a custom field and it is not being set as expected. It sounds like the Reset is evaluating to true when you don't expect it to happen. This would cause your existing Response SLA record to be set to Completed and a new Response SLA record to be started.
Based on your Reset condition, I suspect your Response SLA should not be started if the Assignment group is empty. And your Reset should only happen if the Assignment group changes, and my Incident Response SLA answer provides information on one way to set that up.
Regards,
Ed
