If you have a domain-separated instance like managed service providers (MSP) and have service level agreements defined for individual domains, then you may have faced one or more of these issues:

  • SLA not getting assignedSLA_Service_Level_Agreement-1.png
  • Different, unexpected SLA getting assigned
  • Assignment changing after an update to the record


There could be multiple reasons for these issues; however, we made a few changes to the SLA engine to easily define SLAs in domain-separated instances and address the above mentioned issues.


1. SLA Definition record's "Domain" field


The “Domain” field on the SLA Definition form now determines the domain where SLA should apply. While this field was available even in the previous releases, it had a limited scope beyond which its value wasn’t considered, leading to inconsistent behavior at times. I do not want to get into more technical details here; however, the gist is that you can now completely rely on this field to designate the domain where a particular SLA should apply.


Available in:

  • Helsinki Patch11 and later
  • Istanbul Patch 7 and later
  • Jakarta

domain field_SLA definition.png


If this field is not available on your SLA definition form, then please configure the form layout this way:


  1. Click on the context menu icon on the top left side of SLA definition page, then go to Configure > Form Layout
    SLA definition_configure.png
  2. Find the Domain field from the available list on the left slushbucket and move it to the selected list of fields on the right:

SLA definition_domain field.png


**For releases prior to the ones mentioned above, the Domain field can still be added to the SLA definition form. However, it may exhibit inconsistent behavior as explained before. The recommended workaround is to create the SLA in a global domain, but add a condition field Domain in Start conditions to determine where it should apply, like the image below:


SLA domain field_global domain.png


2. Domain of the task


Now the SLA engine always uses the domain set on the Task. Previously it was observed in some cases (not always) that the domain of the session was used for SLA processing, which led to the removal of SLAs and reassignment based on who updated the record rather than the Caller’s domain. Currently there is no workaround available, so your only option is to upgrade to one of the versions listed above.


3. New proven practices plugin

In the Jakarta release, we introduced a new plugin called the SLA Best Practice - Jakarta: com.snc.best_practice.sla.jakarta. For new customers starting with Jakarta as the very first instance version, it will be active by default. For customers upgrading from a previous release to Jakarta, it is inactive by default, but you can request the plugin through HI by navigating to Service Catalog > Activate Plugin. Just keep in mind that it may break any customizations you may have made. This plugin provides alignment with ITIL best practices, makes changes to the existing SLA notification and escalation workflow, and adds a new field to SLA definition form called Service Level Target which enables filtering, searching and reporting on service level target types. You can learn more about it in the SLA release notes.


Domain field on the form will help create clear SLA definitions and ease the admin life. Also keep in mind that if you use the SLA Best Practice plugin, your existing customizations may break. So make sure you perform enough testing before using it in Production.


Image credits