Why does 'Made SLA' in the incident table report as True when it has failed

[hoggy12]

My question is around incident reporting and particularly around meeting/failing SLA's.

I run a report each month against the Incident database and group them by 'Made SLA'.   To me, this should show a bar chart and each bar split into met and failed SLA.

It does not.   There are incidents in the Met SLA section, that have actually failed the SLA (or one of them).

If I then run a report against the incident SLA table, this then splits out each incident into each of its SLA's, so the number returned is greater, but at least it shows the incident as failing its SLA.

My question is, am I using the Made SLA correctly (I don't see how I am not) and why is this returning incorrect data?

Please see attached document showing screen shots of what I am seeing

Thank you in advance.

Mark

[Harry Campbell2]

I'm guessing those response SLA's have their own definition? You could filter those out your report too.

[hoggy12]

Thank you for your help with this and apologies for the late response.   I thought I had managed to sort this out and was all chuffed with myself.

Ran this months report and found a difference in incidents raised and then the total of incidents in this report (more).

Turns out, when an incident is reopened it creates a new SLA definition on the incident of the same type as the one that was just resolved.   Therefore, the report is picking up 2 (or more) lines of data for each of this incidents, when I only need the one.

I have been playing with the filters, but cannot find a way for it to just pick up one entry, any ideas at all?

Thanks again for all your help

[hoggy12]

Hi there,

I have been wading my way round out system and can see that we do not have anything in place to amend the state of a SLA Definition if it is altered during the lifetime of that record.

How would we go about getting this implemented so that we could differentiate between the active and cancelled definitions?

Thanks again for your help

[Harry Campbell2]

This thread should hopefully give you what you need.

SLA Behaviour

I asked this question some time ago and ctomasi helped me move those SLA's into a cancelled state.

[jesseadams]

Hi Mark,

There are several fields on the task table that are part of the legacy SLA engine - This is actually pre-2010 engine.

Those fields are made_sla, sla_due and escalation_level.

At this point if you're using the 2010 or 2011 engines those fields will not be used as the ability to support multiple SLAs per task mandates that we tracks those details in the task_sla record.

As to why the legacy fields are still available.. there are really two reasons why:

1. We aren't going to drop columns from a table during an upgrade. We want to make sure that if you do have any data in that column you need we're not destroying it

2. The legacy SLA engine is still used by our express customers.

There is actually a really good post from one of our SLA experts in the community that talks about how to overcome some of the challenges customer face with these fields here:

Meet Your SLA Business Requirements without using legacy SLA Fields

Hope that helps!