This article will show how we can have one SLA supporting another. For example, a customer SLA may have multiple supporting SLAs, these may be of type INTERNAL, an Operational Level Agreement, or of type VENDOR, an underpinning agreement. There is nothing stopping one Customer SLA supporting another Customer SLA, but this would be less likely.

As an SLA may have multiple commitments it does not mean that the supporting SLAs are supporting the same set of commitments. The Contact commitment may have a different supporting SLA to the Response or Resolution because different parties may be involved. Similarly, a customer resolution commitment may be underpinned by several vendor SLAs as not all services of a certain type may be resolved by the same vendor.

At the bottom of the article is a little section on Deleting SLAs as many of the error messages that can occur will depend on whether the SLA is supporting other SLAs.

As a reminder from previous articles, we have an active Customer SLA 1029 against the SR object which we have applied against a Service Request.

In the last article we added two additional commitments and so we now have:

• Contact in 2 Hours
• Response in 1 Days
• Resolution in 15 Days

I’ve duplicated SLA 1029 and SLA 1042 was created. I’ve made this an Internal SLA on the Service Desk, which is supposed to also be 2 hours. I’ve lowered the Ranking from 30 to 70 as we only want the Customer SLAs setting the target dates on the Service Request.

I’ve also stripped away the Response and Resolution commitments as the Service Desk is only responsible for the initial contact. While they monitor the Service Requests after this point, the response and resolution are carried out by either internal departments or vendors and on a work order. I’ve made a deliberate mistake and changed the Contact Commitment to 4 hours which is less stringent than the customer SLA that this SLA will be supporting. SLA 1042 has been made ACTIVE.

In the Related SLAs tab, there are two sub tabs – “SLAs That This SLA Supports”, and “Supporting SLAs”. In the SLAs That This SLA Supports tab I have used the New Row button and on the SLA field used the Select Value action. You can see that with a lot of SLAs you will need to filter to find the right SLA, using the Service Group and Service field will make this much easier. There is a button Select SLAs which allows you to add multiple supporting SLAs in one action.

When you select SLA 1029 from the Select Value you will receive a warning – “BMXAA3962E – The commitments of the existing SLA are in conflict with the commitments of one or more related SLAs and will likely lead to an SLA violation.” This is because the supporting SLA has a commitment of 4 hours, but the same commitment on the SLA it is trying to support has the same commitment type of 2 hours which is more stringent, hence it could lead to SLA violations.

After pressing OK, SLA 1042 now supports SLA 1029.

If you navigate to SLA 1029, you will find that it is supported by SLA 1042, the record shows up in the other tab “Supporting SLAs”.

In the previous articles we had applied SLA 1029 or SLA 1036 to Service Request 1307. When you use the Apply SLAs action and then use the View SLAs action you will see that the Internal SLA with just the Contact commitment is also displayed. As it was duplicated from SLA 1029 it has the same matching criteria and so will be a candidate for it being applied to create the Target Dates on the Service Request.

You could say that all three SLAs are applied to Service Request 1307, but 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 allows for Multiple SLAs based on Ranking, and so it happens that only SLA 1036 is used to set the Target Dates on Service Request 1307, it has the highest rank. Now you can see that you would normally have a higher-ranking value (lower rank) for supporting SLAs that are INTERNAL or VENDOR type, if they are on the same object, as these should not be setting the target dates.

I’ve again duplicated SLA 1029 to create SLA 1043 which I have made a VENDOR type. I also changed the Ranking to 70. The Response and Resolution Commitments will be against a work order. When I change the Applies To object to WORKORDER I receive the error message “BMXAA3938E – This SLA cannot be applied to WORKORDER because it contains a commitment of type CONTACT. Please remove the existing CONTACT commitment to continue.” There is no Target Contact Date on a work order, hence the CONTACT commitment will always be missing from the list when you create commitments against work orders.

Further down SLA 1043 I have deleted the Contact commitment to leave the two for RESPONSE and RESOLUTION. I have deliberately made the RESPONSE Commitment longer than the SLA it will support, 30.00 hours is less stringent than the 1 DAY = 24 Hours of SLA 1029. The RESOLUTION Commitment is more stringent at 12 DAYS versus 15 DAYS on SLA 1029.

On SLA 1029 I have used the Supporting SLAs tab and created a 2^nd row, we already have a Supporting SLA 1042 for the Contact Commitment. In the Select Value notice that the existing Supporting SLAs are not shown. I’ve selected SLA 1043 and received the same warning message we saw before. This occurs although the Applies To object is different, WORKORDER instead of SR, and it is at DRAFT status. It is also considering that the Response commitment is in DAYS in SLA 1029 and HOURS in SLA 1043.

Now there are two supporting SLAs to SLA 1029, one an Operational Level Agreement, and the other an underpinning agreement with a Vendor.

If you have been following along through the three SLA articles, you will find that you cannot change status of the new SLA 1043 to ACTIVE. This is because there is an Additional SLA Criteria clause that references the attribute INTERNALPRIORITY which doesn’t exist on the WORKORDER object. Once it has been removed the status of SLA 1043 can be changed to ACTIVE.

If you reapply the SLAs on Service Request 1307 you will have the same three records in the View SLAs dialog, it does not show SLA 1043 because it is not a match, it is against the WORKORDER object.

Incidentally if both the SLA and the Supporting SLA are at INACTIVE state then you do not get a warning when you try to create a relationship between the two SLAs, and you do not get a warning when you change status to ACTIVE on either SLA. Therefore, it is possible to relate two SLAs where the supporting SLA is less stringent than the SLA it supports, without receiving a warning. A case has been lodged with IBM Support.

Deleting SLAs

When SLAs are supporting each other, they also factor in whether you can delete an SLA, or whether an error will be issued.

An SLA at DRAFT status can be deleted, it has never been applied to a record, as to be applied the SLA must be at ACTIVE status, it cannot then return to DRAFT status. 

The last SLA we created was SLA 1043 against the WORKORDER object. If we try to delete it, we will receive the error message “BMXAA3933E – The SLA cannot be deleted because it is currently active and supports another SLA.”

If we make SLA 1043 inactive and then try to delete it, we get a slightly different error message “BMXAA3937E – The SLA cannot be deleted because it supports another SLA.”.

If we had first removed the supporting relationship to SLA 1029 while it remained at active status, then error message “BMXAA3934E – The SLA cannot be deleted because it is currently active.” is received.

If no related SLAs exist and the SLA is at inactive status, then you can delete the SLA, but you will first receive confirmation “BMXAA4125I – Are you sure you want to delete this record?”.

If the SLA has been applied to a record you will get a slightly different set of error messages:

• If we were trying to delete SLA 1042 which is at active status and has been applied to SR 1307, and is supporting SLA 1029, the error message is “BMXAA3931E – The SLA cannot be deleted because it is currently active, has been applied to a record and supports another SLA.”
• If SLA 1042 has a status of inactive then the error is “BMXAA3935E – The SLA cannot be deleted because it has been applied to a record and supports another SLA.”
• If SLA 1042 is at status of active but it no longer supports SLA 1029 the error is “BMXAA3932E – The SLA cannot be deleted because it is currently active and has been applied to a record.”
• Finally, if SLA is inactive and it is not supporting another SLA then the error is “BMXAA3936E – The SLA cannot be deleted because it has been applied to a record.”

If you really want to try and delete the SLA rather than just leave it at INACTIVE status, then you would need to find the service requests where it has been applied. I used the Select/Deselect SLAs action on Service Request 1307 and then when I went to delete SLA 1042, I got the confirmation message “BMXAA4125I – Are you sure you want to delete this record?” which this time I declined.

If you want to delete an SLA that doesn’t support other SLAs then it can be deleted if it is at INACTIVE status and is not applied to a record, even if it is supported by other SLAs. If you accept the confirmation those SLAs will not be deleted, there is no cascade delete.

Incidentally, it would be reasonable to create a synonym of INACTIVE, perhaps INMOD to distinguish between SLAs In-Modification from those which will remain permanently inactive. It is too easy to be making a change to an SLA and then get distracted halfway through, a good reason for entering the SLA Administrator field with whoever is responsible. This way SLAs at INMOD state where the status date was a few days ago, can be questioned to see whether they really should be left at this status.