SLA alerting/category alerting

[gavster]

We have had major problems with Category based alerting, this was basically where if a user was updating a record the problem daemon would enter the record and lose peoples updates, we turned locking on and still recieved the same issue. There was no solution to this so we turned to SLA alerting which works fine apart from one real big problem. If the priority is changed (up or down) the SLA is not re-calculated, so if you change a P1 with an SLA of 1 hour to a P3 with a SLA of 4 hours, the record will fail after one hour.



My managers are absolutley furious with this as SLA's are at the heart of ITIL and a succesful support envoiroment. Priority changes are common in almost every helpdesk so...



Has anyone else experienced similar problems? and if so have/how you rectified them?

[gavster]

Oh were using SC 4.05!

[fid509]

I found this week out that the new SLA will recalculate the alert times if you change the status (open, work in progress, etc.) of the incident. So you probably have to do some calculations in the format control of the form to change the status.

[jcogan]

We run the following subroutine in our problem update format controls:



update: agreement.id in $file~=agreement.id in $file0 (check if the sla has been changed, but you could also use severity.code or any other parameter)



Parameters:

name: NULL#

query: problem.status in $file

time1: open.time in $file

string1: number in $file

index: agreement.id in $file



This forces the SLA alert times to be recalculated based on the new SLA, and status.



If your SLA's are chosen based on the severity.code, you should be able to manipulate the inputs somehow to make it choose the right one and then recalculate.



Try it and see if it accomplishes what you're trying to do.

[fid509]

Are you sure this works? What for application name are you using? NULL# seems a little bit odd too me and if I tried it gave me an error.

[gavster]

I haven't tested yet but it seems hopeful, I will let you know how i get on

[harn145]

Actually, I think he's calling the "sla.problem.change.state.wrapper" application, and the defintion will work if set the "name" parameter as #NULL#

[gavster]

You lot are bloody amazing!!! this works a great! we have been told by Peregrine that this cant be done,

So thanks alot for your help guys!

[gavster]

I have found one smaill problem with this..



it only seems to work if no alert stages have been reached. ie: if a priority 1 has reached an alert stage and then lowered in priority the new SLA is not recalculated. But if a proirity 5 that has not reached alert stages is raised up to a priority 1 the proirity 1 alert stages that have already passed are met.



does any one have any ideas of how to rectify this?

[harn145]

It sounds like the condition in the subroutine calling the change.state.wrapper. Make sure that all SLA affecting items are encorporated in your condition, and that the sla-change call (scripts?) is called before the change state.

Maybe you could elaborate a bit more on the issue you identified.

Is it no longer comming up with "alert stage 1" once it has reached that state (on another SLA)?