Use case :
When an Incident is created as part of an escalation from a Support Request, the SLA of the request will already exist for a certain time.
It should be possible to take that time already spent at the request level into account when calculating the remaining time at the incident level.
Problems with current implementation of fully independent SLA calculations on requests and incidents:
- Escalated incidents need to be resolved within the resolution time allowed by the request SLA. This time is however not predictable
- There is no way to let incident SLA calculations take into account the time spent at the request level before escalation to the incident
A mechanism such as the following would allow handling this used case properly :
- When the request is escalated to a new incident, the request create time is copied to a new incident field (e.g. InitialRequestStartTime_c). (this can either be done via custom After adding relationship rule or be implemented as an OOTB functionality as part of this change)
- NEW FUNCTIONALITY: Allow the Incident SLT calculations to be based on this field instead of the Incident creation time.
Note : when relating a request to an existing Incident, two options will exist:
- keep the existing InitialRequestStartTime_c (if any). This means that the Incident SLT calculations will be based on the initial escalation time
- OPTIONAL / IF FEASIBLE: keep the earlier time (either InitialRequestStartTime_c or the create time of the newly related request).
This will then base the Incident SLT calculations on the related request that has been reported first
(requires SLT calculations to dynamically use this datetime field)
- Incident Service Level Targets can be made to represent overall customer service level targets, as defined at the level of the request.
Any time spent during the attempted resolution at the level of a request will be taken into account at the level of the Incident