Retroactive SLA Not Starting Correctly for Reopened Incidents in ServiceNow

[Urvashi Jain]

Hello ServiceNow community 👋

Today, I want to share a real-time issue I resolved recently related to SLAs not starting retroactively for reopened incidents. This might help you if you handle complex SLA conditions in ITSM implementations.

⸻

Problem Statement

Scenario:
For our client, we had an SLA that should retroactively start even if the incident is reopened after resolution. However, we noticed that:
• When an incident moved from Resolved to In Progress, the SLA did not restart.
• The SLA definition had “Retroactive start” enabled, but the expected behaviour was inconsistent.

⸻

Root Cause Analysis

Upon investigating:
1. SLA conditions were based on Incident State changes.
• Start condition: State is In Progress.
• Stop condition: State is Resolved.
2. Retroactive start field was set to “Created”.
• This worked only when SLA was attached initially upon creation, not upon re-opening.
3. Business Rule evaluation order impacted SLA recalculation.
• The business rule updating a dependent field was running after SLA evaluation, causing condition mismatch.

⸻

Solution

✅ Step 1. Modify SLA Definition
• In the SLA Definition → Retroactive start field, change from Created to State.
• Set ‘Retroactive start condition’ to trigger when state becomes In Progress.

✅ Step 2. Adjust Business Rule Order
• Identify the Business Rule updating category/subcategory that impacts SLA condition fields.
• Change its ‘When’ to ‘Before’ and Order to < 100 to ensure it runs before SLA Engine evaluates conditions.

✅ Step 3. Validate with Test Cases

Tested with below scenarios:
1. New Incident created → Assigned → In Progress → Resolved → Reopened → In Progress.
✅ SLA restarted retroactively as expected.
2. Incident reopened multiple times.
✅ SLA attached every time with correct timings.

⸻

Key Takeaways

🔧 Always ensure Business Rules updating fields tied to SLA conditions run before SLA evaluation.
🔧 Retroactive start needs correct field and condition mapping depending on your process flow.
🔧 Test SLA definitions with multiple lifecycle scenarios to avoid future SLA breaches or miscalculations.

⸻

I hope this solution helps you in your implementations. If you face similar SLA challenges, feel free to share them in the comments. We can brainstorm solutions together.

Regards,

Urvashi Jain

=========================================================
If my response proves useful, please indicate its helpfulness by selecting "Accept as Solution" and " Helpful." This action

Let’s keep learning and growing as a community.

⸻

#ServiceNow #SLA #ProblemSolving #ITSM #DeveloperTips #ServiceNowCommunity #Learning

[Mark Manders]

Am I missing something here? What does the BR have to do with this? 
Also: why put a 'stop' condition on 'resolved'? If you would make 'resolved' a pause condition and 'closed' the stop condition, your SLA would just continue after being reopened. You are now creating new SLA records that aren't necessary. The SLA should stop the moment the Incident is fully resolved and that's only after the caller confirms it (either actively, or by letting the auto closure close the incident).
You now need to report on multiple SLA records for this incident.

[Urvashi Jain]

This is a sharp observation and correct interpretation of SLA design logic. Here’s a clear explanation of what’s happening and what’s being pointed out:

⸻

✅ What they are highlighting:
• Business Rule (BR) relevance – They’re asking: Why is a Business Rule involved here? Because SLA definitions themselves usually handle pause/start/stop conditions. Using a BR externally to manipulate SLAs is unnecessary unless you are enforcing an exception process or custom logic outside SLA conditions.

⸻

✅ On the stop condition for ‘resolved’:
They are saying:
• If you set ‘resolved’ as the stop condition, the SLA will end immediately when the state changes to Resolved, regardless of whether the incident gets reopened.
• Best practice: Set ‘resolved’ as pause condition and ‘closed’ as stop condition.
This way, if the ticket is reopened from Resolved, the SLA resumes from where it paused, ensuring a single SLA record continues tracking until the final closure.

⸻

🔴 Issue with current design:
• Your current setup stops the SLA at ‘resolved’ and then creates a new SLA record upon re-resolve or further updates.
• This leads to multiple SLA records for the same incident, making reporting, SLA compliance checks, and client communications complex and fragmented.

⸻

✅ What should ideally happen:
1. Pause on Resolved: SLA pauses when incident is marked resolved.
2. Resume on Reopen: SLA resumes if incident state goes back to ‘In Progress’ or ‘On Hold’.
3. Stop on Closed: SLA stops when incident is fully closed (either by user confirmation or auto-closure post-resolution time).

⸻

🔧 Summary Guidance:

✔️ Review if your SLA Definition conditions can handle this logic directly instead of an external BR.
✔️ Configure Resolved = Pause and Closed = Stop in your SLA definition.
✔️ Remove unnecessary BR logic if it’s duplicating SLA engine functionality.
✔️ Ensure stakeholders agree on this behaviour, as some organisations may prefer SLA to stop at ‘Resolved’ if business considers resolution as fulfilment.

[Urvashi Jain]

If you want, I can help draft a communication reply or test scenarios to validate these configurations today for your SLA review tasks. Let me know.

[Mark Manders]

You have put my response to your question into chatgpt and are posting it here. What's your point? You haven't answered my questions, nor is it clear if you have resolved the issue or are still in need of assistance?