Can the "Changes to" operator, be used in conjunction with dotwalking? SLA related
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-04-2025 11:48 AM
Hi All,
I am building a SLA definition, using the extended operators "Changes", "Changes From" and "Changes to", but I cant seem to get the SLA Definition to trigger at all - even with the most basic conditions.
So my start condition is super simple:
Priority=2
Assignment Group.Parent "Changes to" XXXXX (where XXXXX is a valid parent group)
So I then create a P2 incident, assigned to a group that has either no parent, or has a parent group of YYYY. I then reassign the incident to a group that does have parent=XXXXX, but the SLA will not trigger at all 😞
I am wondering if it is actually somehow impossible, in a SLA Definition to use "changes to" with a dotwalk.
I also tried some other flavours, using "Changes" and "Changes From", but can't seem to get the SLA to attach.
Did any manage to get this to work in their SNOW instance?
Many thanks all!
(P.S. I know dot-walking is not recommended in a SLA definition, I am aware of that - I am focussed only on the question of Changes To combined with a dotwalk. Also, I know that the extended operators are not enabled by default in the SLA module - but I have a use case where I see no other option)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-07-2025 01:41 AM
Hello @CMH ,
After some further experiments I have come to the conclusion that this requirement is not feasible with just the SLA Definition and the OOTB Incident fields. Additional configuration would be required.
One possible solution would be to create a new true/false field and a Business Rule. I have called the field "Sibling group transfer" in the following examples.
The Business Rule would run "before update", with the condition "Assignment group changes", and has the following advanced script:
var oldGroup = previous.assignment_group,
newGroup = current.assignment_group;
if (!oldGroup.parent.nil() && !newGroup.parent.nil() && oldGroup.parent == newGroup.parent) {
current.setValue('u_sibling_group_transfer', true);
} else {
current.setValue('u_sibling_group_transfer', false);
}
Then the SLA Definition itself would look like this:
I tested this with the following results:
Scenario 1
- Incident assigned to Network group (any state) => Database response SLA not triggered
- Assigned to Chicago Database group (no person; any state) => Database response SLA starts
- Assigned to a person => SLA stops
- Incident reassigned to New York Database group (no person; any state) => no new SLA gets triggered
Scenario 2
- Incident Assigned to Chicago Database group (no person; any state) => Database response SLA starts
- Assigned to a person => SLA stops
- Incident reassigned to Network Group => no new SLA gets triggered
- Incident reassigned to New York Database group (no person; any state) => a second Database response SLA starts
The field and Business Rule could be created on the Incident table, or even the Task table in case these "family" groups also work on other task types and you need similar SLAs there as well.
The other approach suggested by @Kieran Anson would be cleaner, but some effort would be required to determine if the Incident was passed between siblings (the groups within the same "family"), because all we can work with here is the current record.
var MyOwnSLACondition = Class.create();
MyOwnSLACondition.prototype = Object.extendsObject(SLAConditionBase, {
attach: function() {
var task = this.task;
// add code to find out if the task was reassigned between sibling groups
// var siblingGroupTransfer = ...
if (!this._conditionMatches(this.sla.start_condition))
return false;
return (!this.complete() && !this.cancel() && !siblingGroupTransfer);
},
type: 'MyOwnSLACondition'
});
Regards,
Robert
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-17-2025 02:05 AM
Ah I like this idea very much - I will propose it to our developers!
Will keep you posted and thank you for all the help Robert