Response SLA does not trigger when incident assigned directly to an agent - 12-4-2023

[Ben331]

Hello,

I hope you all are doing well! Please see my dilemma below, and let me know if you have any feedback to achieve the following business objective. Thanks for any input the community is able to provide!

I currently attempting to implement response SLA's in our environment to track the time it takes to populate the "assigned to" value when an incident hits a specified assignment group. 

For the most part I have achieved this with the condition logic I've documented below. However, there is one scenario I would like to better handle to align with real-world scenarios. (see example below)

Example: (screenshots attached)

1. Service Desk member sees incident record in the Service Desk backlog queue and knows exactly who to assign incident to on the Network team.
2. Service desk contacts corresponding team member of the Network assignment group informing them of an incoming warm transfer.
3. Service desk member updates assignment group value = "Network" and Assigned to value = "Fred Luddy" and clicks save or update

The result of this action would be a "completed" response SLA for the Service Desk, but no response SLA triggers for the Network team. I would like to be able to reward the Network team's contribution for receiving the warm transfer with a completed response SLA. Is there any eloquent solution within ServiceNow to achieve this? This could also be an issue when an incident is created and directly assigned to an agent (no response SLA generated). If I had to guess, I would say it is because the start and stop conditions are both being met at the same time. However, I would like a response SLA to essentially open and auto complete when this scenario arises.

Condition tab logic as stands: 

Start condition =

Active is true

and

Priority is 3

and

Assignment group is not empty

Pause condition = 

Incident state is On Hold

Stop condition = 

Assigned to is not empty

or

Incident state is one of [Resolved, Closed]

Reset condition = 

Assignment group changes

(Reset action = Complete existing Task SLA)

[Marco0o1]

Hi @Ben331 ,

If I understand correctly you want to have and ACL for each group and save a story that the Service Desk have the log that they have the incident assigned to them. What I can recomend is have an ACL for each group and you can have a third ACL for the resolution of the incident. On this case you will have this as example this:

- Priority 1 Incident

 - Priority 1 Incident Service Desk, the trigger condition and resolution would be similar to "Priority 1 Incident" the only different they would have in the Start condition is to Assigment Group is Service Desk and a new Stop Condition that the group is different to the actual group (On this case different to the rule that trigger the flow "Service Desk")

-Priority 1 Network, This would be similar to Priority 1 Incident Service Desk but for network and you will have the assignment group for them. At the end following the resolution of your incident will be the same but will change for the groups.

The standard ACL for "Priority 1 Incident" can be replaced and only have the other two, using this way you will avoid to use the reset condition.

Hope that help you.

[Ben331]

Hi @Marco0o1 - First off, thank you for your detailed reply. I attempted breaking up the response SLA's into separate definitions for assignment groups (SD and Network), but I still experience the original behavior I am attempting to work around.

I will try and condense the dilemma I am trying to solve - In the real world, teams "warm transfer" all the time (example: they will inform a colleague on another team that they are assigning an incident directly to them). I don't want to restrict teams from doing this, but I still want to measure the receiving team's "response" to an incident.

When Assignment Group A transfers to Assignment Group B and populates an "Assigned To"  value, a response SLA is not created for Assignment Group B. I believe this is because the "start conditions" and "stop conditions" are occurring at the same time, so the system simply does not open a new response SLA. For reference, I have documented my stop/start conditions above in the original question. I would like to implement this in a way that would trigger a response SLA for the receiving team, even if the stop conditions are already met (essentially opening and completing the SLA simultaneously for tracking purposes).

I appreciate any feedback/experience anyone has had with this!

[Alp Utku]

Did you try adding start condition as "Assigned to is not Empty"?

[Ben331]

Hi, @Alp Utku . Thanks for the response. The issue with this approach is that it would prevent our response SLA from generating in the most normal scenarios.

Normal Scenario - Incident enters assignment group unassigned to an individual. Our logic is working correctly as-is for this scenario.

Less Common Scenario I am also trying to cover in my logic - Incident is assigned to a new assignment group and directly to an "assigned to" value at the same time.

In both cases I want a response SLA to be created, in the second scenario, I would like the response SLA to auto-complete. Currently, with my logic as-is, an SLA is not getting generated at all for the second scenario.

I hope that helps, and again, thanks for your feedback.