I want to use SLA to track response "comments" from assignment group to their customers for incidents they have created. I want to maintain a good level of updates and communication such that the Assignment group, gives their customers a new update "comment" every 5 mins, until the incident is complete.
How can we achieve this scenario, and most importantly how can we ensure that, if we need to repair an SLA, it continues to provide accurate results.
There is a common pitfall when thinking about this scenario, which is to use a dynamic condition in one of the SLA condition fields i.e. Start, Stop, Pause and Reset. For example, the reset condition might use a dynamic filter like:
"Assignment group" is (dynamic) "My Groups"
Where the dynamic filter script "My Groups" would be something like:
gs.getUser().isMemberOf(current.getValue("assignment_group"))
Any dynamic condition in an SLA is problematic because it is evaluated at the time the SLA is processed. In this case the user making an update to the incident will be verified against the assignment group. When running SLA Repair (or looking at SLA Timeline or running SLA in Async mode) the HistoryWalker will replay each update and pass it to the the SLA Engine that will then evaluate the dynamic condition using the running user (which is the system user or maint user), but will NOT be the user that made the original update, and will give a different outcome to when the SLA Engine ran in real time.
The Solution: Store the Result Statically
Therefore we need to use a static condition, and move the dynamic aspect to a business rule that stores the user's outcome of being a member of the assignment group or not, in a field that can be evaluated by the SLA condition when reading from history, irrespective of the user who is running the SLA Repair process.
Let's start by creating a new field: commented_by_group of type reference to sys_user_group on the incident table to store the result of the dynamic check.
Now we create a business rule that will populate this field when a comment is added to an incident and the user is a member of the assignment group.
Finally we create our SLA definition with the static reset condition:
Now we create the incident and add comments as different people in different groups and we make change the assignment group to a different group and see what happens to our SLA records.
We can now look at the audit data of the incident to see how we captured the comments made by users that are in the group that the incident is assigned to.
If your SLA condition depends on who made a change, persist that information on the record at the time of the change, so any future replay produces the same result. Here is an example of the SLA Timeline showing task SLA records resetting.
1 Comment
