Trouble\limitation when using Service Commitments to apply SLAs to incidents

CMH
Tera Contributor

3 weeks ago

Hi All,

 

We have many Service Offerings that need to use the same set of SLA definitions, so we had the idea to use Service Commitments.

But it seem that all the Offerings connected to the Commitment, will be treated "as one unit"......

1) So imagine a ticket is with Network-Offering1 (which is linked to a Commitment), and the SLA gets attached just fine.... all good so far.

2) Then the ticket gets assigned to Email-Offering2 (also attached to the same Commitment).... the attached SLA continues to run, which is bad, because Offering2 is being punished with the time consumed in the SLA by Offering1... not fair (they are completely different offerings, from different teams).

 

So it is possible, for me to configure the SLA to complete (or reset of even cancel) when the ticket moves, and trigger a new one to attach for Offering2....but this is where I see a limitation, to do with the retroactive start\pause settings in the SLA, and also the pause conditions in the SLA. I cannot find a way, to get the SLA to consider time previously spent with the original Offering1.

 

So imagine that I adjust the SLA definitions so the old SLA task gets replaced with a new one... imagine a ticket goes like this:

1) Ticket with Offering1, SLA attaches.

2) Change to be Offering 2, the original SLA task cancels and a new one is created.

3) Offering changes again, back to Offering 1. Again the SLA task cancels and a new, 3rd SLA task is attached.

 

It is in this 3rd step we have the issue..... Offering1 is getting a fresh clock in the SLA task, the time they had the incident from before is not counted... now usually, if we were not using commitments (and instead made dedicated SLA definitions for each offering - would means hundreds of definitions though), this could be fixed in the SLA definition, by using retractive start\pause along with a sensible pause condition... like this:-

 

SLA Retroactive start\pause = true

Pause Condition = Service Offering IS NOT Offering1

 

However, because the Commitment uses only one definition, where the whole idea is to save complexity by not explicitly mentioning Offerings in the SLA formula (and therefore not needing hundreds of SLA definitions), there is not a way I can see to set up a pause condition that would achieve the purpose..... 

 

I wonder if anyone had any clever ideas on that? I would greatly appreciate it!

 

 

0 Helpfuls
  • 360 Views
2 REPLIES 2

pr8172510
Tera Guru

2 weeks ago

Hi @CMH,

You've identified a very real limitation with Service Commitments. They work well for simple "follow the ticket" scenarios, but break down when a single incident moves between different Service Offerings that belong to the same Commitment.

 

The Core Issue

When multiple Service Offerings share a single Commitment, the SLA definition is treated as one continuous measurement across all of them. The Commitment doesn't automatically know that time spent with Offering1 should not count against Offering2.

Your attempt to use retroactive start/pause fails because:

  • The pause condition needs to reference the current Service Offering

  • But you don't want to hardcode hundreds of offering names into the SLA definition

  • That defeats the whole purpose of using Commitments

Dynamic PAUSE Condition Using Script 

Instead of hardcoding offering names, use a scripted pause condition that dynamically checks if the current offering matches the offering that SHOULD be running.

In your SLA Definition, where you set Pause Condition:

text
Pause Condition: current.service_offering != sla_task.original_service_offering

But sla_task.original_service_offering doesn't exist by default. So you need to store it.

Step 1: Add a Field to SLA Task Table

Create a field on sla_task table called u_original_service_offering (string)

Step 2: Business Rule on SLA Task - Before Insert

javascript
(function executeRule(current, previous) {
    
    // Get the incident/task record
    var parentRecord = new GlideRecord(current.task_table);
    if (parentRecord.get(current.task_id)) {
        
        // Store the original service offering when SLA first starts
        if (parentRecord.service_offering) {
            current.u_original_service_offering = parentRecord.service_offering.toString();
        }
    }
    
})(current, previous);

Step 3: Pause Condition Script

In your SLA Definition, use this Pause Condition script:

javascript
(function pauseCondition(current, slaTask) {
    
    // Current service offering on the incident
    var currentOffering = current.service_offering;
    
    // Original offering when SLA first attached
    var originalOffering = slaTask.u_original_service_offering;
    
    // Pause if the offering has changed from the original
    if (currentOffering != originalOffering) {
        return true; // Pause the SLA
    }
    
    return false; // Keep running
    
})(current, slaTask);

Step 4: Resume Condition Script

javascript
(function resumeCondition(current, slaTask) {
    
    var currentOffering = current.service_offering;
    var originalOffering = slaTask.u_original_service_offering;
    
    // Resume only if back to original offering
    if (currentOffering == originalOffering) {
        return true; // Resume
    }
    
    return false;
    
})(current, slaTask);

This allows the SLA to pause when the ticket moves to a different offering, and resume when it comes back, preserving the elapsed time correctly.

0 Helpfuls

CMH
Tera Contributor

yesterday

Hi pr8172510,

 

Thanks for sharing your view, it seems like we see it the same way- which is reassuring - thank you

0 Helpfuls