Default SLA Workflow
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-22-2011 04:35 AM
Can I use the Default SLA Workflow for the following purposes?
1. Incident SLA is broken, need an escalation for this (priority 2)
2. Wait 4 hours after SLA broken (reminder) (priority 2)
3. Priority 3, need an escalation 24 hours after SLA broken (incident)
Do somebody have any examples?
- Labels:
-
Orchestration (ITOM)
-
Service Mapping
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-22-2011 06:11 AM
Hi Soren,
The Default SLA Workflow creates 2 events:
- sla.warning
- sla.warning.breach
It does that at 3 time intervals, and uses it to send a mail to the task assignee, and later to the manager of the task assignee:
- At 50% of elapsed time > sla.warning
- At 75% of elapsed time > sla.warning
- At 100% of elapsed time > sla.warning.breach
Now depending on what you want to do with that flow (like for instance, "need an escalation for this" does not entail any information on how the business rules would apply to this), you could create a new SLA workflow, and make that the workflow for all SLA definitions.
In most cases however the out of the box flow suffices by issuing the solution differently:
1. When sla.warning.breach event > script action > do something to ticket / escalate to manager.
2. When sla.warning.breach event > script action > create scheduled job for over 4 hours > do something to ticket / escalate to manager.
3. When sla.warning.breach event > script action > create scheduled job for over 24 hours > do something to ticket / escalate to manager.
If needed, you can also add conditioning in your script action to when a SLA should be breached and when not, but it's better to have the sla.warning.breach act as indicator of a proper breach of SLA. This means that all conditioning should be done in the SLA definitions and the scripts should only be used to send warnings or updates to tickets, or clean up dependencies when SLA's are no longer needed (a customer agreeing to solve issues on a best effort basis for instance).
Take care in automating stuff like this as there are a lot of dependencies in the system for SLA's that really should not be edited or altered in any way (Default SLA Workflow being one of them).
I hope this bit of generic information helped, but you'd really have to elaborate on your case if you'd want a specified solution.
Regards,
Wesley