- SLA not getting assigned
- 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.
- Helsinki Patch11 and later
- Istanbul Patch 7 and later
If this field is not available on your SLA definition form, then please configure the form layout this way:
- Click on the context menu icon on the top left side of SLA definition page, then go to Configure > Form Layout
- Find the Domain field from the available list on the left slushbucket and move it to the selected list of fields on the right:
**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:
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.