SLA Incident - need to knom best Practice.

[Karine_M]

Hi all,

I have some question about SLA and the best practice.

1- SLA on Incident or on Case ?

Some incidents are created from case.
For these incidents, the SLA must start from the case creation date. What is the best solution:
- Update the incident creation date (or an another date field ?) with the case creation date (via a Business Rule) and create an SLA definition on the incident table with a retroactive date on the created ?
- Create a definition on the case with a Start condition on incident is not empty and retroactive date on created ?

2 - SLA Schedule source

I have SLA definition whose schedule source is based on Incident field with source field is configuration item.schedule.

What happens if the CI is empty? Can we set a default schedule?

Regards,

Karine

[J Siva · Accepted solution]

Hi @Karine_M 
1. SLA on Incident or on Case ? -> Create a custom date/time field on the Incident form and assign it the case creation date when creating the incident from the case. Then, in the SLA definition, check the 'Retroactive start' option and select the newly created custom date field under the 'Set start to' field

2. SLA Schedule source -

I don't think we can configure the default SLA schedule. However, as a workaround, you can create two SLA definitons.

1. The first one is based on the Incident field with the source field as configuration item.schedule. Add the condition configuration item.schedule IS NOT EMPTY in the 'Start condition'.
2. The second one is based on the actual schedule you want to use as the default, with the 'Start condition' as configuration item.schedule IS EMPTY.

Hope this helps.
Regards,
Siva

[J Siva · Accepted solution]

Hi @Karine_M 
1. SLA on Incident or on Case ? -> Create a custom date/time field on the Incident form and assign it the case creation date when creating the incident from the case. Then, in the SLA definition, check the 'Retroactive start' option and select the newly created custom date field under the 'Set start to' field

2. SLA Schedule source -

I don't think we can configure the default SLA schedule. However, as a workaround, you can create two SLA definitons.

1. The first one is based on the Incident field with the source field as configuration item.schedule. Add the condition configuration item.schedule IS NOT EMPTY in the 'Start condition'.
2. The second one is based on the actual schedule you want to use as the default, with the 'Start condition' as configuration item.schedule IS EMPTY.

Hope this helps.
Regards,
Siva

[Shree_G · Accepted solution]

Hello @Karine_M ,

Few suggestions below :

1. Overwriting the Incident creation date would not be suggested as this may impact on other reports and would not be reflecting the correct details.

2. If at all necessary and only Cases are taken into account, You can have SLA set on Case table rather than Incident. In this case SLA will reflect true case creations and would be focused on Cases only.

3. If SLA needs to be on Incident table only then would suggest below option, which will cover Case as well.

> Create a custom filed on Incident e.g. "Case creation date", populate it with the Case's creation date using any script.

> In SLA Definition on Incident Table, set Retroactive Start on the custom filed Case creation for Case's SLA or "Opened at" for other incidents without cases.

[Mark Manders]

An SLA is an agreement between you and the company/user that has created the Case. If an incident is needed to resolve the issue, that shouldn't matter to the company/user that created the Case. The Case needs to be resolved within x time.

Since you probably need the team handling the incident to know when it should be resolved, add the Case creation date as field on the incident table to have it retroactive start on that date, but be aware that this should not be the SLA that you are communicating to your end user.
There is an issue, however, in case the Incident creation is not automated by something. If it is manually created from the Case, it's not fair to the resolving team to have little time to resolve it. They can't help it that it takes 6 hours before they are informed. Never overwrite system fields like 'created' or 'updated'. If you need the date/time there, create a custom field, but wonder why you are creating the SLA at all. 
Is the Incident resolving team looking at the SLAs to define what they pick up when? Then you need it, but if not, you can also just copy the breach date from the case sla to the Incident for them to filter on that.

And I agree with J Siva. There is no 'default' schedule. Create 2 definitions. One on the default if CI schedule is empty, and one if not (or prevent CI to be empty: have the default schedule on every CI if not explicitly set otherwise and have a default CI on the incident if it's not filled (create a 'not specified' ci)).