Tracking the Assigned Group When an SLA Breaches

[MohamedG7003017]

Why doesn’t the task_sla table include a reference field to store the assignment group at the time the SLA is being tracked?

For example, there could be a case where an incident breaches an SLA while it was assigned to L1, but later gets reassigned to L2. In such situations, I’d like to identify which group was responsible when the SLA actually breached.

Is there a reason this isn’t captured by default, and what’s the best way to track it?

[AndersBGS]

Hi @MohamedG7003017 ,

Try to take a look by the sla breakdown by assignment group.

[Connectmustaq]

Hi @MohamedG7003017 ,

 

The task_sla table in ServiceNow does not include a direct reference field to capture the assignment group at the exact time an SLA breach occurs by default.

 

Reasons Why Assignment Group at Breach Is Not Captured by Default

1. SLA Context Focus:
   The SLA record (task_sla) focuses on tracking SLA definitions, states, start/end times, elapsed times, and breach status relative to the Task record itself. It tracks the task’s overall status, not point-in-time ownership snapshots.​

2. Data Model Simplicity:
   Assignment groups can change multiple times during SLA tracking, and capturing each change would require maintaining a history of assignment groups linked to SLA progress—significantly complicating the data model and impacting performance.​

3. Separation of Concerns:
   Assignment group history is stored in task audit/history tables separately from SLA tracking. Mixing this data could complicate maintenance and degrade reporting performance.

To Track Assignment Group at SLA Breach Time

• Use Task SLA Business Rule or Scheduled Job to Capture SLA Breach Context

• Maintain Assignment Group History in Task Audit

• Reporting Approaches

Because assignment groups can change frequently during SLA progress, ServiceNow doesn’t store this point-in-time group by default on the SLA record. The best way to track this is by adding a custom field on task_sla and setting it via a Business Rule when the SLA breaches, capturing the current assignment group on the related task at breach time.

This approach cleanly preserves the exact ownership context for each SLA breach without major platform changes while integrating well with built-in audit and reporting capabilities

If it is helpful, please hit the thumbs button and accept the correct solution by referring to this solution in the future it will be helpful to them.

Thanks & Regards,

Mohammed Mustaq Shaik