Multiple Task SLAs Being Created on CSM Case When Customer Replies

[RohitD027682673]

Hi Community,

I am troubleshooting an issue with ServiceNow CSM Cases where multiple Task SLA records are being created/attached to the same Case whenever a customer replies.

Issue

For some CSM Cases, the following behavior is observed:

1. A Case is created.
2. An SLA is correctly attached to the Case.
3. The customer replies to the Case.
4. As part of processing the customer reply, the Case status/state changes to In Progress.
5. A new Task SLA is then created for the same Case.
6. If the customer replies again, another SLA may be created.

This is not happening for every Case. It is occurring only for certain Cases.

The issue is also not limited to one particular SLA Definition. Multiple SLA Definitions can exhibit the same behavior.

Important observation

When the Case is initially created, only one SLA is attached.

After a customer reply, another SLA gets attached.

More customer replies can result in additional SLA records being created.

There is currently no Reset condition configured on the affected SLA Definitions.

Troubleshooting performed so far

• Confirmed that there are no duplicate SLA Definitions with the same configuration.
• Confirmed that the issue can occur with multiple SLA Definitions.
• Confirmed that the issue occurs only on some Cases.
• Checked the Reset condition — it is not configured.
• Observed that the Case status/state changes to In Progress when the customer replies. 
  
  Questions
  1. What are the recommended steps to identify why a new Task SLA is being created after a customer reply?
  2. Can a Business Rule on sn_customerservice_case cause an existing SLA to be evaluated/started again?
  3. Can a Business Rule on task_sla that updates the parent Case potentially contribute to repeated SLA creation?
  4. Which logs/debugging tools would you recommend to identify the exact transaction that creates the second task_sla record?
  5. Are there specific OOB CSM Case Business Rules or customer-reply processes that I should check first?
  6. What would be the best way to compare an affected Case with an unaffected Case to identify the difference?

  
  Any guidance on how to trace the exact reason for the second Task SLA creation would be greatly appreciated.

  Thanks!

[AyushKumarM]

Hello @RohitD027682673 ,

This is almost certainly expected OOB SLA engine behavior, not a bug — and it doesn't require a Reset condition to reproduce.

The SLA engine only skips creating a new task_sla if an active one already exists for that SLA Definition + task. If your Stop condition evaluates true (even momentarily) — e.g. state moves away from "In Progress" during reply processing — the existing task_sla gets marked Cancelled/Completed. If the Start condition then evaluates true again in a later transaction (state back to "In Progress"), the engine creates a brand new task_sla. No Reset needed — Reset is only for restarting the same SLA counter, this is a totally separate stop→restart path.

To confirm: pull sys_audit on the Case's state field around the reply timestamp — you're likely seeing more than one transition (e.g., a hop through Awaiting Info/On Hold or two separate update transactions), even if the "before/after" only shows In Progress → In Progress. Also check sys_audit on the first task_sla's stage/active fields — if it flips to Cancelled right before the second one appears, that's your proof.

Quick checks:

• Review the Start and Stop conditions on the affected SLA Definitions (not just Reset) — see if Stop can plausibly go true during reply handling.
• Check if any reply-processing logic (Flow/inbound email/BR) updates the Case in more than one transaction.
• Check if task_sla has a BR that writes back to the Case — that can trigger the SLA engine again and create a loop-like re-evaluation.
• Enable debug logging on one affected SLA Definition (enableLogging field / SLA Logging properties) and reproduce in a sub-prod instance with Debug Business Rules on, to see the exact transaction order.
• If Retroactive Start is enabled on any of these definitions, check that too — it's a known contributor to duplicate-looking task_sla records on reopen/state-flip scenarios.

Compare an affected vs. unaffected Case's state audit trail — the affected one almost certainly shows an extra state hop the unaffected one doesn't.

Thanks.

[RohitD027682673]

Hi @AyushKumarM ,

Thanks for the detailed explanation. I have gone through the suggested checks and have some additional findings from my instance.

I checked the Start, Stop, Pause, and Retroactive Start configuration of the affected SLA Definition:

• Start condition: Based on Priority and Category.
• Stop condition: The SLA stops when the Case Status is Closed.
• Pause condition: The SLA is paused when the Case Status is either Awaiting Customer Response or Resolved.
• Retroactive Start: Enabled, with the retroactive start time set to the Ticket Opened Date.
• There is no Reset condition configured on the affected SLA Definition.

I also reviewed the task_sla records for an affected Case. As shown in the attached screenshot, the same SLA Definition is attached to the same Case multiple times.

The important observations are:

1. The same SLA Definition is attached multiple times to the same Case.
2. The Start Time is the same for these SLA records.
3. The Created Time is different for each SLA record.
4. The Stage of each SLA remains "In Progress", including the earlier SLA records. In other words, the previous SLA does not appear to have been cancelled or completed before the new SLA is created.
5. Each time the customer replies, another instance of the same SLA is attached to the Case.
6. There is no Reset condition configured on the SLA Definition.

I also checked the sys_audit history of the affected Case, specifically looking for State changes around the time the additional SLA was created. I found only one relevant entry corresponding to the initial Case creation. I did not find evidence of an intermediate Case State transition that would explain a Stop → Start cycle.

Based on these findings, I would appreciate guidance on how to trace what is causing the SLA engine to create a new task_sla record.

Specifically:

1. Can an SLA Definition with the same Start condition (Priority + Category) create another task_sla for the same Case while the existing task_sla is still In Progress?
2. Could Retroactive Start, configured to use the Ticket Opened Date, contribute to this behavior?
3. What SLA engine logs or debugging options can I enable to identify the exact reason why a new task_sla is being created?
4. Should I investigate any Business Rules, Flows, or other automation on the task_sla table that could trigger another SLA evaluation?
5. Is there a specific field on task_sla that I should audit to determine what caused each additional record to be created?

The attached screenshot shows the key behavior: same SLA Definition + same Case + same Start Time + different Created Times, while all the SLA records remain "In Progress."

Additionally, the issue is not limited to this particular SLA Definition. I have observed the same behavior with multiple SLA Definitions, and it occurs only for certain Cases.

Any guidance on how to trace the exact SLA engine transaction or determine what is triggering the additional task_sla creation would be appreciated.

Thank you.

[Tanushree Maiti]

Hi @RohitD027682673 

Check KB: KB2129160 Customer Service Cases are completing and re-attaching Task SLAs multiple times