Multiple SLAs on a Single Incident – How Does ServiceNow Handle It?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4 weeks ago
Hi Everyone,
I have a question regarding SLA behavior in ServiceNow when multiple SLAs are applied to a single Incident.
Specifically:
- Do all applicable SLAs run simultaneously on the same Incident?
- How does the system track and display multiple SLA timers?
- What happens if the SLAs have different start, pause, or stop conditions?
- Is there any priority or conflict resolution between multiple SLAs?
Additionally, I have one more scenario:
- What happens if two SLAs are created with the exact same condition (for example, both for Priority = P1) and both get applied to the same Incident?
- Does ServiceNow treat this as a valid scenario, and how should it be handled from a best practice perspective?
- Is this considered a good practice or something that should be avoided?
I would really appreciate if someone could explain this with a real production example and share best practices to handle such situations.
Thanks in advance!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Yes, all applicable SLAs run simultaneously on the same incident — ServiceNow creates separate Task SLA records for each matching definition. You can view each one separately and see their individual breach status. They don't "compete."
Different start/pause/stop conditions work fine. For example, one SLA triggered by Priority=P1 and another by Assignment Group=EMEA — both evaluated independently, both active at the same time.
There's no built-in priority system between SLAs. However, you can configure cancel conditions. For instance, if priority upgrades from P3 to P1, set the P3 SLA to cancel on priority change. Enable "Retroactive Start" on P1 so it calculates from ticket creation, not the upgrade time.
Avoid duplicates with identical conditions. Use the "Allow Multiple" setting on SLA Definitions to prevent the same definition from creating multiple records. Two P1 SLAs = duplicate tracking with no benefit and maintenance headaches.
Best practice: use distinct matching conditions (Priority, Assignment Group, Category) rather than overlapping definitions. Keeps your SLA landscape clean and reporting clear.
