SLA Timers not showing.

[Paul Trenter]

Please bear with what could well be a noob question.

We have now grown to the point where I want to include automated SLA timers within our Service Manager rather than just raising tickets without.

I've configured SLAs and designed rules which seems to work.  If I log an incident the correct SLA is showing linked in the call.  I've also configure start and stop timers within the Business Process for Respond and Resolve Timers.  Using the example Business Process for the automated tasks. 

Where I am stuck though is on the Request List screen.  I've added columns for Respond By and Resolve By but the fields aren't being populated with any dates.

I don't think it's the business process, as I changed the Incident workflow in the Service to the example 'Hornbill with Timers'.  Tested raising an incident and still no date/times for SLA in request list.

Any help appreciated.

[Steven Boardman]

Hi @Paul Trenter

Quick question when you are looking at the SLA information on the request are you seeing Respond or Resolve Dates and Times?

 

Which is then not showing on the request list view (unlike mine which is showing below)

Thanks

Steve

[Paul Trenter]

Hi Steve.  No, I'm not seeing the timers within the call either.

I just see the Service Level Name and the option to Pause underneath.

[Steven Boardman]

@Paul Trenter ok so we know that your rule against the CSS Service Desk & Noc service is selecting the Standard SLA (8X5) Service Level Agreement so a couple more questions:

Against the Service do you have one or multiple SLA's defined?

If you have multiple i assume you have created rules under the Manage Rules tab to select your Standard SLA (8X5) ?

inside your Standard SLA (8X5) do you have one or multiple Service Level Targets defined?

* Do they have a response and or resolution target defined? and if so does this correspond to the timer you are starting in the business process? i.e if a resolution target is set for the Service Level Target are you using the Start resolution timer not the start response timer option in the business process?

* If you have more than one Service Level Target inside your chosen Service Level Agreement, have you configured rules inside the Service Level Agreement to decide which Service Level Target for the Service Level Agreement should be used?

So basically a rule to chose the SLA and then a rule in the SLA to choose the SLT inside the SLA.

Hope that makes sense?

Steve

 

[Paul Trenter]

Hi Steve,

Yes as we have a number of customers in the system my plan is to have the one service then a number of SLAs within under each company heading.  Then 'manage rules' to auto assign correct SLA based on Organisation.

At the moment though I just have 2 SLAs under the service.   That Standard SLA and one for a Customer while I've been testing the rule(which works ok).  In Standard SLA there are 5 Priorities configured, all with Response and Resolve Times set:

In the business process I have a start and stop response timer and then a start and stop resolution timer

Thanks, Paul

[HHH]

Following since I noticed we have the same problem.

In the Business process we start both Response and Resolution timers and then stop response timer after ticket is assigned and prioritized and resolve timer when ticket is resolved

[Paul Trenter]

One other thing I've noticed, and might not be relevant.  Is that when I create a new 'Test SLA', the option on there is then to 'Delete' rather than 'Remove' as shown on the other 2 SLAs.  Might be because I didn't create those other 2 myself?

[Steven Boardman]

@Paul Trenter when viewing SLA's in a service, you can only delete Service Specific SLA's you have created not Corporate SLA's which might be used across multiple services - the different SLA types are indicated by the Yellow or Green line on the righthand edge

[Paul Trenter]

Thanks Steve yes just noticed and was about to query that.

[Steven Boardman]

@Paul Trenter i can see you have multiple Priority named Service Level Targets inside your SLA - could you show us a screen shot of the Manage Rules tab inside that SLA which is used to control which Priority named Service Level Target will be invoked when the Standard SLA (8X5) SLA is invoked?

So once the SLA is chosen we still need to have rules for which Service Level Target is used, if no rules match then no Service Level Target for that SLA will be used.

https://wiki.hornbill.com/index.php/Service_Level_Rules_Builder

[Paul Trenter]

@Steven Boardman I have set 5 Rules on that SLA, one for each of the 5 priorities in the same format as below:

[Steven Boardman]

@Paul Trenter thanks

If the rules are all based around the request Priority, when is the Priority set in your Business Process in comparison to your start response or resolution nodes?

If you use the start resolution or response nodes before a priority is set, then it would make sense that the SLA is invoked but no rule would match as no priority is set so no Service Level Target would be invoked?

If this is the case, you could use a Suspend await Priority node ahead of the start timers, to ensure a priority is set before starting the timers?

This may no be the issue if you are choosing the Priority as part of progressive capture or if you are setting the update priority in your business process ahead of starting the timers but worth checking.

Maybe a screen shot of the business process?

Thanks

Steve

 

[HHH]

@Steven Boardman

That seems to be the issue in our case so now I'm in a catch 22 situation. Response time is from ticket is created until it's been assigned and prioritized but I cannot start clock until priority is set....

Hmmm, a challenge awaits.

Thanks a lot for pointing this out though.

[Steve Giller]

You can create an SLA of "Incoming" (or whatever title works for you) and have "No Match" set to that - this way the timers are running.
Once the priority is set, you use the "Set SLA" node and it will change to the appropriate SLA.

I don't know if that resets the timers - if not, it doesn't matter, carry on as normal.
If so, we could use an enhancement to (optionally) stop that happening, but you should be able to test for a response breach, store it in a Custom Variable, and then you can report on that where necessary.

[Paul Trenter]

I did have the 'Get Priority' set after stopping the response timer so I've jiggled some nodes .  Still getting no timers in the test calls though.  Here is the current Business Process:

[Steven Boardman]

@Paul Trenter if you put your start response timer after your wait for incident priority that should work for your response timer

[Steven Boardman]

@Paul Trenter another consideration is to ask your agents to set the priority in progressive capture - make the priority mandatory so you will have a priority set and you can start your response timer immediately.  Obviously this only covers the scenario where the ticket is logged over the phone, so you could have a decision node to see if the priority has been set, if it has start response timer, if not suspend and wait for priority to be set or you might be able to get a bit smarter and use the answers provided in the customer facing progressive capture on the portals to say something like:

* If answer a = x set priority to P1

* If answer a = y set priority to P2

This way you are not asking your customer to set their own priority but you are using the answers they gave to interpret the correct priority level and use the update request > priority business process option before starting your response timers.

[Paul Trenter]

Hi Steve yes the current Progressive Capture asks for Priority at the moment.  Made the changes as directed but still no luck.

I am running this on a test Business Process rather than messing with the main one we use for now.  For testing I've set it as the Workflow for Incidents in the Service.  Is there a way to confirm which Business Process is being used just to make sure?  Do I also need to change the defaultBPMProcess.incident in Settings?

[Victor]

@Paul Trenter : in addition to @Steven Boardman suggestions:

From the previous screenshot, I can see you are using the SLM functionality (https://wiki.hornbill.com/index.php/Service_Level_Agreements). If SLM is enabled, then in both "Start Response Timer" and "Start Resolve Timer" nodes, the request ID parameter is mandatory (I don't think this is covered by the wiki, to be honest). Therefore the BP needs to have the request ID value when the "Start Response Timer" node is reached. This can be achieved by having a "Get Request Details" node right before the timer start.

 

Regarding this:

13 minutes ago, Paul Trenter said:

Made the changes as directed but still no luck.

So, following Steve's suggestions, you now have the "Start Response" further down the line, the important bit is that you now have it after "Get Requestor Type", which is a "Get Request Details" type of node, and this covers what I suggested above.

It could be that you have "no luck" because the changes you made are not active? Did you publish the BP after the changes were made and BP was saved?

[Paul Trenter]

Thanks Victor. I've now added the 'Get Request Details node(below) right before the Start Response Timer.  When I look at the earlier Get Requestor Type Node, all the variable are set the same.  Is that right?

As for publishing, I now have a few previous versions it seems but the correct one is listed as published.  Can you delete the old versions?  Not so important really.  Still no timer when all saved and tested.  Sorry this is such a pain, probably something easy I'm missing.

[Victor]

16 minutes ago, Paul Trenter said:

I've now added the 'Get Request Details node(below) right before the Start Response Timer.  When I look at the earlier Get Requestor Type Node, all the variable are set the same.  Is that right?

Yes, that's right, the "Get Requestor Type" node is the same as "Get Request Details", so is not needed as long as the "Start Response" (and/or "Start Resolve") node is (anywhere) after the "Get Requestor Type" node.

You only need "Get Request Details" node as I suggested if you plan to keep the original configuration, which is to have the "Start Response" right at the beginning of the process. In other words, in the original configuration, you do need the "Get Details " node, in the second configuration you don't.

 

29 minutes ago, Paul Trenter said:

Still no timer when all saved and tested. 

Hmm... is the same error in the logs. I need to investigate in bit more detail. I need to look at your configurations in the instance using the admin account. Let me know if that's ok (or not)

[Victor]

@Paul Trenter right, looking at some test requests, I think I found the "bottleneck"   ... the issue seems to happen because Hornbill is unable to find a Service Level to associate with the request and this is related to SLAs configurations on the service. So, looking at the service you have 3 SLAs associated with it: RUHB, Test and Standard (simplified names). Each of these SLAs has their own Service Levels for which you defined rules within each SLA. That's fine and correct but there is another configuration which seems it was missed.

If a service has multiple SLAs associated with it then you need to create rules that will associate an SLA with a request. When the SLA is associated with a request, Hornbill moves to next step which is to associate a Service Level (SL) based on rules defined within the SLA. So, basically, you have two set of rules: one deciding which SLA and one deciding which SL. Seems you have covered the SL rules but not SLA rules.

Back to the service and looking at the SLA rules, there is only one rule configured which is to associate the RUHB SLA if the organisation on the request is "...". This criterion is not met in your test requests, therefore Hornbill is unable to associate an SLA, hence is not able to associate a SL and this is why the issue occurs.

What need to be done is to add more rules to cater for all possible scenarios to make sure an SLA is associated with a request. This is valid for Service Levels as well. Since you have 3 SLAs I would need to know what is the criteria for each SLA (on which conditions one of the three is associated with the request) so I can advise on how to set these rules. This  of course, if you need some assistance setting these  

 

[Paul Trenter]

Thanks Victor.  I did just test with an account that should hit that RUHB rule but didn't work.  To make it as simple as possible for now deleted the 'test SLA' and I've added another rule to use the other SLA for all other Orgs.  Tried another Org contact but still no joy.

[Victor]

@Paul Trenter looking at 710, I see that it did set the SLA on it (the RUHB SLA) but it did not associate a Service Level. This means on RUHB SLA, there was no rule with criteria that matched the request. Digging a bit deeper into the Service Level rules within the SLA it seems it will associate a Service level based on priority. But all the priorities within the RUHB  SLA rules do not exist. For example, on 710, the priority is "P2 - High Business Impact". The rule criteria will try and match a priority of "P2 Priority". As you can see these don't match. My guess is that priorities were changed/updated at some point after the rules were created but the rules were not updated to cater for the new priorities.

 

I would also suggest creating the rules in such way to cater for any possible scenario. I'll try and explain what I mean: for example, on RUHB SLA you associate a Service Level for P1, another for P2 and another for P3 or P4 or P5 (I am ignoring the last rule, the org one, as it is actually an SLA rule and it is redundant on the Service Level level and IMO should be removed from there). So, I would change the third rule and instead of criteria being "priority is P3 or P4 or P5" to "priority is not P1 or P2". Basically, what I am trying to say there should be a rule that would say something along these lines: "if none of the above rules match then use this" ... the equivalent of the "No Match" branch in the business process decision nodes. Hope this makes sense  

 

[Paul Trenter]

Yes it does make sense. In my defence those rules were not created by me.  I'm not sure why they are named different as if you click in the field it give you the list of correctly named rules to choose from.

I've tested, now have a date and time showing and you have me out of your hair...............until next time  

Thanks @Steven Boardman & @Victor for taking the time to look at this.  You've been a massive help.