Last Updated on October 29, 2023 by maximosecrets

This is the second article in the series on Service Level Agreements. In this article we look at the filter criteria and matching process when applying a single SLA to a Service Request (SR). You can find the first article where we manually applied SLA 1029 to Service Request 1307 here: http://maximosecrets.com/2021/11/08/service-level-agreements-1-an-introduction/

SLA Filter Criteria

What we showed in the first article is a bit of an unusual way of explicitly applying an SLA to a Service Request, by selecting it. If you had hundreds of SLAs finding the right one to apply would inevitably lead to mistakes. The usual method is to enter filter criteria on the SLA and allow it to be matched to the data entered on the Service Request, by using the Apply SLA action. Do not use the Apply SLA action too early, not until you have completed the details on the Service Request that you want to use for matching against the bank of SLAs, otherwise, you may just have the wrong one applied.

There are several places where filter criteria can be entered on the SLA.

Note. The Applies to Object, SR in our case, is also used as part of the matching process, and qualifies as one of the filters.

Filter by Service

The first one should be the default for most clients embarking on a path to improved Service Management and we have already entered these two fields, a Service Group of FACILITY and a Service of ENVIRON. A Service Request with these two fields set with the same value will be candidates for matching to SLA 1029. 

Note. If these two fields are null on the Service Request, then SLA 1029 will not be a match. If on the SLA these two fields are both null then it would be a match to a Service Request that had values for these two fields, it would also be a match if these two fields were left blank on the Service Request.

Filter by Date

With SLAs there is often a written agreement and there is bound to be at least a Start Date, probably also a Finish Date with a proposed Review Date. These three fields can be found in the Dates section. 

If the Reported Date on the Service Request is on or after the SLA Start Date and before or on the SLA End Date or the SLA End Date is null, left open, then the SLA is a match, it is a candidate for being applied to the Service Request.

This is a commonly used as part of filter criteria. When the SLA reaches its End Date, either extend it, if the criteria has not changed, or make it INACTIVE and duplicate the SLA and change the criteria on the new SLA. Then you have a record of the SLA criteria that was applied to Service Requests, Work Orders and other records that may now be in history.

Notice, to make changes I did need to use the Change Status action to make the SLA inactive. You cannot move back to DRAFT status, the default status.

Filter by Site

SLAs are often associated with the assets or locationsA physical place where assets exist and where work can be performed. More of a particular site. I entered BEDFORD in the SiteA structural element of a Maximo database that is used for data separation. More field and the Organization EAGLENA was entered.

When Maximo is searching in the bank of SLAs to find the ones which are a possible match there is an initial query of SLAs and both the Start/End Date and Site are in this initial query. This will help to reduce the SLAs which will need to be examined to see if they are a match. 

Note There is no Site field in the Service Provider version of the SLA application. There is an Organization field, but it is hidden, and populated if you enter a Vendor.

Filter by Classification

The next most common part of filter criteria used in the SLA matching process is to use the Classification field. This need not be the classification at the leaf nodes but can be anywhere in the hierarchy where it makes sense. In our example, for Service Requests at BEDFORD site which reference any of the “End User Issue \ Facility” issues then a match will be made, and SLA 1029 will then be a candidate for being applied. If the Classification on the Service Request is left empty, then SLA 1029 will now not be a match.

Filter by Calendar

There are two Calendar sections, but it is the Applies To Calendar which is used in filter criteria during the matching process. If the Reported Date on the Service Request appears within the periods defined by the calendar and shift, then a match is made, and SLA 1029 will be a candidate for being applied. In our example, the DAY/DAY calendar/shift is Monday to Friday 07:00 to 15:00. If the Reported Date occurs within this time, it is a candidate match, if it was reported after 15:00, then it would not be a match. Facilities teams use this where the calendar/shift is the operational hours of the facility they are managing. You might use this to distinguish between responses that occur during the day shift from other shifts, when there may be a reduced maintenance team.

Filter by Vendor

An SLA can reference a Vendor, in this case BURSAW. A vendor can be used when the type is CUSTOMER and the Applies To object is SR, it isn’t just reserved for VENDOR type SLAs. If the Vendor on the Service Request is left empty, then SLA 1029 will not be a match. For SLA 1029 to be a match the Service Request must also reference vendor BURSAW.

Filter by Asset/Location

Sometimes SLAs are specific to a set of locations and/or assets and these also act in the filter criteria for matching to the primary asset or location of a Service Request or Work Order. In our case, we will have a faster response for Conference Room issues over other parts of the building and so I have selected the four conference room locations on each floor of the OFFICE location, CONF100, CONF200, CONF300 and CONF400.

When you use the New Row button the Location and Asset are mutually exclusive, if you enter a value in the location field then the asset field will be blanked, and vice versa. The Site field is used to filter the selection of locations and assets. You could remove the filter and enter an asset for say the TEXAS site, however, there is no point it will never be used as a match, because we have already said that the filter criteria are assets and locations in the BEDFORD site, it can’t be in both places at the same time. If you wish to set up an asset in the SLA for when it is in the BEDFORD site, then I’m afraid that you need to do this when the Asset’s site says BEDFORD, as the site field in the supporting object (SLAASSETLOC) is read-only. 

Filter by Additional Criteria

In the section called Additional SLA Criteria there is a single field to enter a SQL Where clause and the SQL Expression Builder to help you get the syntax correct, and most importantly to use the Test Expression button to validate it.

The most common use of this for Service Request based SLAs is when the response time is dependent on the internal priority. The Where clause derived was “internalpriority <=2”. SLA 1029 will be a candidate SLA if the internal priority is 1 or 2. 

Filter by Asset Type

The final part of the filtering criteria is to use an Asset Type. Here, we have selected the FACILITIES assets. SLA 1029 will not be applicable for assets with an asset type of IT or for assets with no asset type.

Notice, I have changed status to make the SLA Active. It is now time to test the SLA using the filtering criteria.

The Matching Process

When you use the Apply SLA action on a Service Request or Work Order there is an initial query which tries to filter out as many SLAs as possible from the bank of Active SLAs that are applicable to the Applies To object, in our case a SR. After the initial query, Maximo needs to look through each of the SLAs in turn to see which are candidates for being applied. With many SLAs this process may take a couple of seconds. You can reduce the time by adding more filter criteria to your SLAs that are in that initial query. As this has differed between versions and whether you are using SLA or the Service Provider version SLA(SP) then I am not going to say what is in the initial query, but I would recommend running a SQL trace to see what it is, and then designing your SLAs accordingly.

Before we test SLA 1029, let’s first recap on the total set of filter criteria we have entered:

• Service Group = ‘FACILITY’ and Service = ‘ENVIRON’
• Reported Date between 01-Nov-2021 00:00 and 01-Jan-2023 00:00
• Site = ‘BEDFORD’
• Classification begins 1 \ 103
• Vendor = ‘BURSAW’
• Location in (CONF100, CONF200, CONF300, CONF400)
• Internal Priority <=2
• Asset’s Asset Type is FACILITIES

All of these statements must be true for SLA 1029 to be matched to Service Request 1307.

I have used the Select/Deselect SLA’s action to delete SLA 1029 which had been applied as part of the first article. Then used the action again to create a new row and Select SLA’s where the radio button setting is Show Filtered SLAs. I was not surprised when no SLA rows were shown. The Service Request doesn’t have much data yet, to match against.

On Service Request 1307 I have entered:

• Service Group of FACILITY and Service of ENVIRON
• Classification of 1 \ 103 \ 10301 \ 1030101 which is “End User Issue \ Facility \ Heating/Air \ Too Hot”
• Internal Priority of 2
• Vendor of BURSAW
• Location of CONF100
• Adjusted Reported Date (and Affected Date) to 02-Nov-21 14:00 to make sure it fits within the calendar and the SLA Start and Finish dates.

The Site was already BEDFORD. There is no asset referenced. After retesting, still no SLA is found.

On Service Request 1307 I have now entered Asset 11240 which has an Asset Type of FACILITIES. In response to the warning “BMXAA5327W – The asset you have entered does not reside in the current location. Would you like to update the location with this new asset’s location – BR240? Clicking Close will return you with no changes to the asset or location.” I responded with the No button. SR 1307 now references asset 11240 and location CONF100.

I have used the Select/Deselect SLA’s action and used the new row and in the Select SLA’s dialog SLA 1029 now shows as a filtered SLA. It is a match. I will apply this SLA to the SR 1307, by using the hyperlink.

All of the filter criteria must exist on the Service Request for a match to occur. You can experiment with this by Deselecting the SLA, changing one element at a time and seeing whether the SLA is a match, it probably won’t be. 

Between each Filter By element there is a logical AND between the SQL Where statements that are being generated behind the scenes.

On Service Request 1307 the SLA Applied field is now checked and the Target Start is calculated as 05-Nov-21 14:00. Was that a surprise, the commitment was 1 DAYS, why isn’t it 03-Nov-21 14:00, one day after the Reported Date?

SLA Calculation Calendar

In the SLAs application there are two sections with calendar information:

• The Applies To Calendar is used for filtering whether an SLA is applicable to the target record where it will be applied. Specifically does the Reported Date exist in the time periods defined by the Calendar and/or Shift.
• Calculation Calendar is used to calculate the target dates, for Service Requests this is Target Contact, Target Start and Target Finish.

The reason why Service Request 1307 had a Target Start date 3 days later than the Reported Date is because if the applied SLA has no Calculation Calendar it uses the Applies To Calendar. This is logical, if an SLA is only applicable Monday to Friday 07:00 to 15:00 then the target dates would be expected to follow the same calendar. The DAY shift is 8 hours long and there are 24 hours in 1 DAYS, the commitment value for the Response commitment. 24 hours after a Reported Date of 02-Nov-21 14:00 using the DAY/DAY calendar/shift gives a Target Start date of 05-Nov-21 14:00.

We can easily test this by removing the Applies To Calendar from SLA 1029.

Then, by deselecting SLA 1029 from Service Request 1307 and using the Apply SLA action. The message received was SLA 1029 was applied. The SLA Applied checkbox is selected. The Target Start date is now 1 day later than the Reported Date at 03-Nov-21 14:00. A quick check of the action View SLAs shows SLA 1029 applied, and on this SLA the Response Time was calculated as 03-Nov-21 14:00. 

Notice, Organization, Calendar and Shift at the end of the table window are empty. If there is no Applies To Calendar and no Calculation Calendar on the SLA then a 24-hour clock is used.

I have now added the same calendar as the Calculation Calendar for SLA 1029. If we reapply the SLA, we should get back to the same date as we saw before.

Our expectations were correct the Target Start is 05-Nov-21 14:00. Notice, the View SLAs action now shows the Calculation Calendar/Shift that was used.

If the Service Request was reported on Friday 05^th November 2021 at 14:00 then the Target Start would be 24 working hours later on Wednesday 10^thNovember 2021 at 14:00. Saturday 6^th and Sunday 7^th are non-working days on the Calculation Calendar.

Ranking – When multiple SLAs are a match

I have duplicated SLA 1029, it created SLA 1036. I have given SLA 1036 a ranking of 30 and then changed status to Active.

I used the Select/Deselect SLAs action to remove SLA 1029, then used Apply SLA action. From the View SLAs dialog, you can see that SLA 1036 was applied, this is because a Ranking of 30 is higher than the null Ranking on SLA 1029.

I’ll change the ranking on SLA 1029 and set it to 25.

Back in the Service Requests application on SR 1307 if you use the Apply SLA action you will receive the warning “BMXAA3955W – An SLA has already been applied to this SR. Reapplying an SLA will potentially recalculate and override existing target dates on the SR. Do you wish to continue?”. I answered OK, and SLA 1029 was applied. This is, of course, marginally faster than using the Select/Deselect SLAs action to remove the SLA first.

There are multiple SLA’s that are a match but based on the current setting in OrganizationsA structural element of a Maximo database which is used for data sharing and is often aligned to a legal entity of an organisation. More – SLA Options, only a single SLA can be applied. The one that is applied is the one with the highest ranking, which we have now confirmed is the one with the lowest Ranking value.

On SLA 1036 I have changed the Commitment to a RESOLUTION type with a value of 7.00 DAYS. There is no Unit of Measure for WEEKS. When applied this will create a Target Finish date on the Service Request.

Now with two different types of commitment SLA 1029 (RESPOND) and SLA 1036 (RESOLUTION) which are both a match, I reused the Apply SLA action on Service Request 1307, and it made no difference, only SLA 1029 was applied. This is because only a single SLA can be applied. If this is how you want to work then you need to add multiple commitments to the same SLA, but there is a way to apply multiple SLAs which we will examine in the third article in this series on the Service Level Agreements application.