When the service type on an incident is changed, there are two possible behaviours, as far as the violation date/time is concerned. The choice of behaviour depends on the setting of the option set_sla_evt_open_date.
We have a customisation where a change in the priority of an incident results in a change in the service type. We do not find either of the current behaviours satisfactory.
If set_sla_evt_open_date is uninstalled or set to 'No', then start_date is set to the current date/time, i.e. the SLA clock restarts when the service type is changed. This can result in too much time before SLA violation.
If set_sla_evt_open_date is set to 'Yes', then the value of start_date is taken from open_date, so the SLA clock keeps going. Also if the service type is changed while the incident is suspended, the time suspended so far is ignored. CA explain this behaviour on the basis that the original service type was incorrect, so the violation time is determined by the open date/time and the new service type, ignoring the old service type and the suspension so far. This can result in too little time before SLA violation, including the case of immediate violation.
What would be better for us?
I would suggest a third behaviour which preserves the proportion of the time to violation. This would need a new option.
Suppose an incident has a service type where violation occurs after four hours, and the service type is changed after one hour to a new service type with violation after two hours.
At the point where the service type is changed, It has used up 25% of its time to violation based on the old service type. It should therefore have 75% of its time to violation remaining, but based on the new service type, i.e. 90 minutes.
It is possible that the current time falls outside the hours in the workshift, or that subtracting 90 minutes takes you outside the workshift. In these cases an adjustment will need to be made.