Service Level Agreement Rules - What is "Company" used for?

[samwoo]

Good afternoon,

I have been setting up the Service Level Agreement functionality, to keep in with support prior to the removal of the old functionality.

I have been setting it up to auto-set the SLA based on the Company the Customer works for. But this is not working at all... it is setting the SLA to the top-most in the list of SLA's against the Service.

I then wondered if "Company" was used against the request, and there is a field called h_company... so I then had a look at the bpm configuration - specifically the update request node, and there isn't any way to set the "Company" of the request.

Can you advise on how I can set the Service Level based on the Customer's company?  Most of the Services applies to all Companies (3 of them) but they have different SLAs.

Thanks,

Samuel

[David Hall]

Hi @samwoo

Company in this case refers to a company defined within the organisational groups configured in the admin tool to which Hornbill users can belong e.g.

 

and within the entry you can assign users...

So if annab was the customer on the request, the company criteria will check against the company she is assigned to (e.g. Dave H Inc in this example).

Hope that answers your question but if not let me know.

Kind Regards,

Dave.

[Alberto M]

@samwoo, 

Be aware that the company field in the request could not be 100% reliable depending on the company you have set in the users and in the sites, as the logic behind it is:
 

1. When a request is raised and a user selected as the customer on the request the values populated for h_company_id and h_company_name will be from the companies associated with that user

2. When on an existing request, when a customer of the request is changed with another user the values populated for h_company_id and h_company_name will be from the user associated site specifically the company associated with that site. 

 

We've detected this because in some requests we found that the company was not what we were expecting (we can have users from different companies associated to the same site).

 

Regards,

A

[samwoo]

Hi @David Hall,

That's great thank you - it wasn't very clear on the Wiki Pages where that comes from.

So the users have already been assigned to the relevant company a while ago.  I even went in as a test user for the company that comes second in the SLA list... 

When I logged a ticket as that test user, the ticket was assigned to the first SLA in the list... despite that SLA looking at a very different company.

Below is my test...

Here is the SLA rules for the second company - the one I expected to be assigned to based on the company my test user is set up against.

Here are the SLA rules for the first company. I have some duplicate Companies since I initially (a long time ago) made one of them a child of the main company accidentally.  This is the SLA that is incorrectly being assigned to my test user.

Here is the company for my test user (starting with W)

But the test ticket I raised is being incorrectly assigned to the wrong Service Level

[samwoo]

Looks like I'm missing some text from the end of my previous post...

"Is there a way to debug this, or to see exactly what is happening?"

In addition, I've gotten reports that for some new tickets, they are being assigned to the incorrect company-based SLA.

Here is an example:

This person is a part of the company beginning with W, and for some reason this request is point to the SLA related to the company beginning with O. 

[samwoo]

46 minutes ago, Alberto M said:

@samwoo, 

Be aware that the company field in the request could not be 100% reliable depending on the company you have set in the users and in the sites, as the logic behind it is:
 

1. When a request is raised and a user selected as the customer on the request the values populated for h_company_id and h_company_name will be from the companies associated with that user

2. When on an existing request, when a customer of the request is changed with another user the values populated for h_company_id and h_company_name will be from the user associated site specifically the company associated with that site. 

 

We've detected this because in some requests we found that the company was not what we were expecting (we can have users from different companies associated to the same site).

 

Regards,

A

I don't use Sites in my SLA's and all users (hopefully) should be assigned to a single Company, so do you think my set up should be working, without the issues you were experiencing?

[samwoo]

Wait do I have to set up these rules within the Services for each Service as well? I was hoping defining the rules at the top level (outside of Services) would suffice?

 

[David Hall]

@samwoo

You can create the SLA as a global SLA (which I believe is what you have currently) but you will need to link it to the services that will use it, this can be done with the link field at the top of the service -> SLAs -> Configuration tab, start typing the name and and SLA should be listed for you to select and link.

 

[samwoo]

Hi David,

Sorry I have been rushing about doing some work on this that I didn't say that all the Services have the SLA's against them for all the companies.

[David Hall]

Hi Sam,

Ok so just to try and make it clear in my mind...

1. Do you have 1 or multiple global SLAs?

2. Do you multiple SLs defined within the/each SLA?

 

[samwoo]

Hi @David Hall,

1. Yes - I have multiple global SLAs, but there are 2 main ones that are used for most Services
   1. One of the SLAs is for the main company (let's say Company W)
   2. The other SLA is for two other companies that we manage the IT Support for (lets say Company O or Company B )
       
2. Yes - I have Service Levels described as Priorities 1 to 5 in both main global SLAs, each with the Response and Resolution Targets set.

In each of the SLAs I have rules that define which Service Level should be used. The rules primarily check for:

1. The Company the user works for
2. The Priority set against the request (P1, P2, P3, P4, P5)
3. For the P3 Service Levels I have an additional condition to only be used if the Request Type is Incident
4. For the P4 Service Levels I have an additional condition to only be used if the Request Type is Service Request

All of our Services have the SLA that looks for Company W.

Most of these Services also has the SLA that looks for Company 0 or Company B.

In the case of my test user, he works for Company W. When the ticket is raised, it is being assigned to the SLA that links to Company O or Company B...

Thanks,

Samuel

[David Hall]

@samwoo

Thanks for the detailed explanation.  

So the process the app follows when determining the SLA and then the SL should go as follows:

Based on the service set against the request...
1. Get all SLAs associated to that service. 
2. If only 1 SLA is returned then use it otherwise check for SLA Rules
3. If no SLA rules found then use the first/top SLA that was returned
4. If SLA rules found then process in order from top to bottom and return when a rule matches

With an SLA Determined we then process for SL
5. Get all SLs associated to the SLA
6. If only 1 SL is returned then use it otherwise check for SL Rules
3. If no SL rules found then use the first/top SL that was returned
4. If SL rules found then process in order from top to bottom and return when a rule matches

If I understand correctly, its the initial SLA selection that is incorrect, if it seems to be returning the first SLA in the list each time then perhaps you could try putting a different SLA to the top to determine if it is just defaulting to the first result.  If so then this would suggest no rules are set for the SLA selection (note there are two sets of rules, 1 for SLA and one for SL).  If this is not the case and it is still selecting the same SLA as before then it seems there is something incorrect with the rule criteria being checked in which case we can look further into that.

If you have no joy there then we can schedule something to review the config and see if we can understand the root of the problem.

Kind Regards,

Dave

[samwoo]

Hi @David Hall,

Thanks for sending the details of the process - I think that would be a good fit for the Wiki pages.

In terms of my issue, I have reordered the SLA against the Service and it appears to have picked up the first Global SLA in the list.  It also assigned a SL from the Global SLA to the request too.

You mention that this is due to there not being any rules in the Global SLAs to determine which one to use, but both Global SLAs have rules in them... one to check for Company W (and priority) and the other one to check for Company O and Company B (and priority).

Then you mention there are two rules configuration (SL and SLA) - can you confirm that setting the rules against the Global SLAs themselves should be more than enough?

Or should I also be assigning rules via the Service SLAs section against a Service as well?

If really hope I don't have to go through every single Service to set this up to select the Service SLA rules... but I did a test by adding the rules to the Service SLA rules area - mimicking what I already had against the Global SLAs themselves, with the Service SLA Rule for Company O and Company B at the top and the Service SLA Rule for Company W at the bottom.  Doing this, then raising a ticket has assigned it to the correct SLA... despite the rules being the same as the ones in the Global SLAs rules.

Thanks,

Samuel

[David Hall]

Good Morning @samwoo

Ok so I think I now understand what is happening. 

Currently you have created global SLAs and within the SLAs you have created multiple SLs (P1,P2 etc) and you have created rules within the SLA to determine which SL to select which is all correct.

However, when you go to a service and link the global SLAs... if you link multiple SLAs to a service (which I believe you have done for your different Orgs W,B etc) then you would need to create rules within that service to tell it which SLA to select, otherwise it won't know and will default to the first SLA in the list.  Once the SLA is determined it will then process the rules in the SLA to determine the SL.  

If you want to avoid creating rules within each service to determine the SLA, then I think you would need to use a single Global SLA (e.g. not one for each Org  W,B etc) and then associate that one SLA to all of your services.  That global SLA will be chosen automatically without any rules and then within your global SLA you could create some additional SLs and rules for each Org needed e.g.

P1
P2
P3

Would become

W - P1
W - P2
B - P1
B - P2

etc.  You can then adjust the rules in the global SLA to check if Org == W use W - P1 etc.

 

Hope that makes sense, does that help to explain what you are currently seeing happening?

Kind Regards,

Dave.

 

[samwoo]

Hi @David Hall,

Just confirming that your advice to just have the 1 Service Level Agreement with different Service Levels for the different companies have worked.

Now the next issue is why isn't the response timer and/or resolution timers not showing for some tickets... despite the Service Level Agreements and Service Levels being set correctly.

My guess is due to the order of the nodes in the BPM (which sets the priority and starts the timers) ... 

In tickets where the Response and Resolutions Timers have not been set, the Priority is set AFTER the timers have started.

In tickets where the Response and Resolutions Timers have been set, the Priority is set BEFORE the timers have started.

Can you confirm that this is correct? Does this likely mean that I will need to update all the BPMs to change the ordering of the nodes? There is no mention of this (that I can find on the Wiki) alongside the other information you provided above.

Many thanks for your assistance with this,

Samuel

[David Hall]

Hi @samwoo

Ok glad to hear we're making progress.

Regarding the starting of the targets/timers, essentially the answer to your question is yes, wherever you place the start timer node in the BPM, it will be looking at the request data at that point in time and will apply your rules based on that, so if the priority is not set but you have referenced it in your rules then you will have the scenario where the SLA/SL is not applied.

As an outsider to your organisation/processes its hard for me to say what the preferred course of action is in this case, but essentially you could do one of two things...

1. Adjust BPMs as needed to ensure the start SLM nodes are placed after the relevant data has been captured against the request (this would normally be the most logical and straightforward option)

2. You could create essentially a holding SL for requests where the priority is not set e.g. a "P - Unknown / 0" with default response/resolution times and set this with a new rule for when priority is not set.  With the service manager setting guest.app.view.ITSM.serviceDesk.slm.enableAutomatedSLChanges enabled, when the priority is changed or set on the request it will then automatically re-run the service level rules and it would then update it to use the appropriate SL for the priority 

Hope that provides some further guidance... let me know if you have any further questions.

Regards,

Dave.