Every incident will have an escalation point that has the "Is breach" checked (hopefully your escalations are configured to only have this checked on 1 escalation action per SLA). What you need is an extra crtieria to check the status of that escalation point, in your case you only want the breached ones so you want the criteria to be where the status = expired.
The incident object also has an 'Is Breached' field that you can query against - this only becomes True when an escalation marked as being 'Is Breached' expires... (eg at 100% of your SLA)
Bit simpler than having multiple criteria, and it means your working with the incident object direct which can also simplify things.
This might appear twice as I'm having problems with my internet at the moment.
You are correct Stu, but there is a trap here and that is why we try to get you to write the query based on the Escalation Point rather than the incident. The 'Is Breach' flag gets set when as escalation point that has the flag set expires. If you are only measuring one SL in your process then using the Inicident flag is fine. The trap is that once the flag is set, it never gets unset. So, if you are measuring both the breach of an initail response and the overall resolution, you can't tell which of the breach points triggered the setting of the Incident flag.
As I see it, there are a couple of fundemental things to implement with SL's that will assist 'easy' breach reporting. The first is the design that you are already discusuing and Stu M has correctly added the need for the Status = Expired criteria to be added to the query. The second is that when you build your Response Levels and add the Escalations, make sure you name the Escalations the same irrespective of the RL that they are linked to. So, if I was measuring Inital Response and Resolution, I would have these two Escalation names present against every RL. This means that when you run a query to show the breach information, by addind a third criteria of Escalation Name you can segregate out the different stages of the process.
Just as a final thought, reporting on breached SLA's is one thing, but I'd suggest we rather new about the ones that were going to breach soon, so take the query that you have designed to report on breached SL's and replace the Status = Expired criteria with the criteria Expirey DateTime in the next 24 hrs for example. You will then have a workload list that highlights all porcesses about to breach.
Hope that makes sense and helps.
"Just as a final thought, reporting on breached SLA's is one thing, but I'd suggest we rather new about the ones that were going to breach soon, so take the query that you have designed to report on breached SL's and replace the Status = Expired criteria with the criteria Expirey DateTime in the next 24 hrs for example. You will then have a workload list that highlights all porcesses about to breach.
Great idea Andy, never thought of that this could be a workaround to solve the issue i have, where i wanting to get detail of the remaining time of resolution so the helpdesk would know which cases about to breach eventhough we have escalation point offcourse.
Is there any way to get the records on color basis? - I mean SLA color basis, say RED!
Now current query shows which are in GREEN and RED. I need only the RED ones.