Understanding Retroactive Start and Retroactive Pause/Stop in SLA (ServiceNow)

[ny424436]

Hi everyone,

I’m trying to understand the concept of Retroactive Start and Retroactive Pause/Stop in SLA within ServiceNow, but I’m a bit confused about how they work in real-world scenarios.

I have a few questions:

1. What is the exact purpose of Retroactive Start and Retroactive Pause/Stop in SLA?

2. Under what conditions does Retroactive Start trigger, and how does the system calculate the actual start time?

3. For Retroactive Pause/Stop, how does ServiceNow determine the correct past time for pause or stop?

4. In which real-life scenarios should we enable these options, and when should we avoid using them?

It would be really helpful if someone could explain this with a practical example related to a real incident.

Thanks in advance!

[Vishnu-K · Accepted solution]

Hi @ny424436 ,

These options exist because the SLA engine evaluates conditions at the time a record is saved. But sometimes the condition that should have triggered a start, pause, or stop happened earlier in the past. Retroactive options handle that by looking back at the audit history and applying the correct time.

Retroactive Start — Instead of starting the SLA timer from now, ServiceNow looks at the audit log and backdates the start to when the condition was first true. For example if an incident was created 30 minutes ago but the SLA only attached now, Retroactive Start will correctly set the start time to 30 minutes ago rather than the current moment.

Retroactive Pause and Stop — Same idea. If the incident moved to Awaiting User Info 2 hours ago but the SLA engine missed that transition, Retroactive Pause will backdate the pause to 2 hours ago so that waiting time is correctly excluded from the elapsed time.

Enable these when accurate timing from the true origin or past state changes is important for compliance or reporting. Avoid them if your audit history is incomplete because the calculation depends entirely on accurate historical data.

Reference: https://www.servicenow.com/docs/bundle/washingtondc-it-service-management/page/product/service-level...

If it helped you please do mark it as helpful and accept the solution

Thanks,

Vishnu

[Pavan Srivastav · Accepted solution]

Great set of questions! Here's a thorough breakdown of both concepts with real-world context.

---

What is Retroactive Start?

Normally, an SLA timer starts at the moment the SLA attaches to a record. But sometimes, the SLA attaches late — the record was already created a while ago, and the clock should have started earlier.

Retroactive Start tells ServiceNow:

"Don't start the SLA clock from now — go back and start it from when the triggering condition was actually met."

How does the system calculate the start time?

ServiceNow looks at the audit history of the record and finds the first moment the SLA's start condition became true, then sets the breach time accordingly.

For example, if the SLA condition is Priority = High and the record was set to High 2 hours ago but the SLA only attached now — with Retroactive Start enabled, the clock starts 2 hours ago, not now.

---

What is Retroactive Pause / Stop?

Similarly, SLA pause or stop conditions may have been met in the past, but the system only evaluated them later.

Retroactive Pause/Stop tells ServiceNow:

"If the pause/stop condition was already true at some point in the past, honor that past timestamp — don't use today's time."

ServiceNow again scans the audit log to find when the condition first became true and applies the pause/stop from that historical moment.

---

Practical Real-World Example

Scenario: P1 Incident — SLA configured with 4-hour resolution target

Timeline of events:

Time	What Happened
09:00 AM	Incident INC001 created with Priority = P3
09:45 AM	Priority escalated to P1 (SLA should have started here)
10:30 AM	SLA Definition runs its scheduled evaluation and attaches to INC001
11:00 AM	Incident put On Hold (SLA should have paused here)
11:30 AM	SLA engine evaluates the pause condition

---

Without Retroactive Settings:

• SLA Start → 10:30 AM (when it attached) — 45 mins of breach time already lost
• Pause → 11:30 AM (when evaluated) — 30 mins of extra time incorrectly consumed
• Breach time calculated as: 10:30 AM + 4 hrs = 2:30 PM

With Retroactive Start + Retroactive Pause:

• SLA Start → 09:45 AM (when P1 was actually set) ✅
• Pause → 11:00 AM (when On Hold was actually set) ✅
• Breach time calculated as: 09:45 AM + 4 hrs − paused time = accurate and fair

---

When to Enable vs. Avoid

✅ Enable when:

• Your SLA evaluation runs on a scheduled basis (not real-time), so there's always a gap between condition met and SLA attachment
• You have Priority-based SLAs where priority can change after creation
• You want accurate compliance reporting — especially for audits or regulatory requirements (e.g., GDPR breach notification SLAs)
• Your team uses On Hold / Awaiting Info states that should retroactively pause the clock
• You're in ITSM or HRSD where breach accountability matters

❌ Avoid when:

• Your SLA attaches in real-time via Business Rules — retroactive calculation adds unnecessary overhead
• The record's audit history is unreliable or sparse — the system won't find accurate timestamps
• You want the SLA to reflect agent response from the moment they saw it, not from a system event
• Retroactive calculation causes confusion for agents who see a breach warning on a ticket they just opened
• You have high-volume tables where audit log scanning could cause performance issues

---

Key Things to Remember

Retroactive Start and Retroactive Pause/Stop are independent settings — you can enable one without the other depending on your business need.

The accuracy of both features depends entirely on audit logs being enabled on the relevant fields (Priority, State, Assignment Group, etc.). If field-level auditing is turned off, ServiceNow has no history to look back into and the retroactive logic won't work correctly.

Both settings live in the SLA Definition record under the "Retroactive" section — always validate with a test incident before enabling in production, as they can significantly shift breach timestamps on existing open records.

---

Here's a step-by-step guide to configure and test both settings.

---

Part 1 — Configuring Retroactive Settings in SLA Definition

Step 1: Navigate to SLA Definition

• Go to Service Level Management → SLA Definitions
• Open an existing SLA or create a new one (e.g. "P1 Incident Resolution - 4 Hours")

Step 2: Set the Basic SLA Details

Field	Example Value
Name	P1 Incident Resolution - 4 Hours
Table	Incident [incident]
Type	Resolution
Duration	4 Hours
Schedule	24x7
Workflow	(your breach workflow)

---

Step 3: Define Start Condition

• Under the Start section, set:
  • Condition: Priority is 1 - Critical
  • ✅ Check "Retroactive Start"

This tells ServiceNow — "Start the clock from when Priority was first set to Critical, not from when this SLA attached."

---

Step 4: Define Pause Condition

• Under the Pause section, set:
  • Condition: State is On Hold
  • ✅ Check "Retroactive Pause"

---

Step 5: Define Stop Condition

• Under the Stop section, set:
  • Condition: State is Resolved OR Closed
  • ✅ Check "Retroactive Stop"

---

Step 6: Verify Auditing is Enabled

This is critical — without it, retroactive logic has no data to work with.

• Go to System Definition → Dictionary
• Search for table: incident, field: priority → confirm Audit is checked
• Repeat for state field
• Alternatively go to System Properties → Audit and confirm incident table auditing is on

---

Part 2 — Testing in a Dev Instance

Follow this exact sequence to validate your configuration works correctly.

Test Case Setup

Step 1: Create a new Incident

• Priority = P3 - Low
• State = New
• Note the created time (e.g. 09:00 AM)

Step 2: Wait 2–3 minutes, then change Priority to P1 - Critical

• Note this timestamp (e.g. 09:03 AM) — this is when SLA should start

Step 3: Wait another 2–3 minutes, then change State to On Hold

• Note this timestamp (e.g. 09:06 AM) — this is when SLA should pause

Step 4: Wait another 2–3 minutes, then change State back to In Progress

• Note this timestamp (e.g. 09:09 AM) — SLA should resume here

---

Step 5: Verify SLA Attached Correctly

• Scroll down on the Incident to the SLA (Task SLA) related list
• You should see your SLA record attached
• Check the following fields:

Field	Expected Value
Start Time	09:03 AM (when P1 was set) ✅
Business Time Left	Should reflect ~4 hrs minus time elapsed since 09:03
Planned End Time	09:03 AM + 4 hrs
Stage	In Progress

---

Step 6: Check Pause Was Honored Retroactively

• Open the Task SLA record (click into it from the related list)
• Look at the SLA Timeline or Pause Duration field
• The pause duration should reflect time from 09:06 AM (On Hold set) to 09:09 AM (resumed) = 3 minutes

---

Step 7: Resolve the Incident

• Change State to Resolved
• Check the Task SLA record — Actual End Time should reflect when State was set to Resolved, not when the engine evaluated it

---

Part 3 — Common Mistakes to Watch For During Testing

SLA not attaching at all? Check that your Start condition query matches exactly. Use the "Test Condition" button on the SLA Definition to validate against your test incident.

Retroactive Start not working? Most likely cause is auditing not enabled on the priority field. Go verify the dictionary entry.

Start time still showing current time instead of past? Check if another Business Rule is attaching the SLA and overriding the retroactive logic. Look in sys_script for SLA-related BRs on the incident table.

Pause duration showing zero? The state field audit may be off, or the pause condition doesn't exactly match (e.g. condition says On Hold but your State value is on_hold — check the exact value vs. label).

---

Part 4 — Useful Navigation Reference

What	Where
SLA Definitions	sla_definition.list
Task SLA records	task_sla.list
Audit History on a record	Form → Right-click header → History → Audit
Field Audit settings	sys_dictionary.list → filter by table + field
SLA Logs / Diagnostics	sla.do in URL (SLA repair tool)

---

Bonus Tip — SLA Repair Tool

If you've enabled Retroactive Start on an existing SLA Definition and want it to apply to already-open incidents, ServiceNow provides a built-in repair tool:

• URL: yourinstance.service-now.com/sla.do
• This recalculates SLA timestamps on existing open records based on audit history
• ⚠️ Always run this in dev/test first — it can shift breach times on live tickets

---

[Dr Atul G- LNG · Accepted solution]

Hi @ny424436 

https://youtu.be/1AW-_D9DZqg

https://youtu.be/X7T6fviU1hg

Here are my videos which help you to understand the same.

[Vishnu-K · Accepted solution]

Hi @ny424436 ,

These options exist because the SLA engine evaluates conditions at the time a record is saved. But sometimes the condition that should have triggered a start, pause, or stop happened earlier in the past. Retroactive options handle that by looking back at the audit history and applying the correct time.

Retroactive Start — Instead of starting the SLA timer from now, ServiceNow looks at the audit log and backdates the start to when the condition was first true. For example if an incident was created 30 minutes ago but the SLA only attached now, Retroactive Start will correctly set the start time to 30 minutes ago rather than the current moment.

Retroactive Pause and Stop — Same idea. If the incident moved to Awaiting User Info 2 hours ago but the SLA engine missed that transition, Retroactive Pause will backdate the pause to 2 hours ago so that waiting time is correctly excluded from the elapsed time.

Enable these when accurate timing from the true origin or past state changes is important for compliance or reporting. Avoid them if your audit history is incomplete because the calculation depends entirely on accurate historical data.

Reference: https://www.servicenow.com/docs/bundle/washingtondc-it-service-management/page/product/service-level...

If it helped you please do mark it as helpful and accept the solution

Thanks,

Vishnu

[Pavan Srivastav · Accepted solution]

Great set of questions! Here's a thorough breakdown of both concepts with real-world context.

---

What is Retroactive Start?

Normally, an SLA timer starts at the moment the SLA attaches to a record. But sometimes, the SLA attaches late — the record was already created a while ago, and the clock should have started earlier.

Retroactive Start tells ServiceNow:

"Don't start the SLA clock from now — go back and start it from when the triggering condition was actually met."

How does the system calculate the start time?

ServiceNow looks at the audit history of the record and finds the first moment the SLA's start condition became true, then sets the breach time accordingly.

For example, if the SLA condition is Priority = High and the record was set to High 2 hours ago but the SLA only attached now — with Retroactive Start enabled, the clock starts 2 hours ago, not now.

---

What is Retroactive Pause / Stop?

Similarly, SLA pause or stop conditions may have been met in the past, but the system only evaluated them later.

Retroactive Pause/Stop tells ServiceNow:

"If the pause/stop condition was already true at some point in the past, honor that past timestamp — don't use today's time."

ServiceNow again scans the audit log to find when the condition first became true and applies the pause/stop from that historical moment.

---

Practical Real-World Example

Scenario: P1 Incident — SLA configured with 4-hour resolution target

Timeline of events:

Time	What Happened
09:00 AM	Incident INC001 created with Priority = P3
09:45 AM	Priority escalated to P1 (SLA should have started here)
10:30 AM	SLA Definition runs its scheduled evaluation and attaches to INC001
11:00 AM	Incident put On Hold (SLA should have paused here)
11:30 AM	SLA engine evaluates the pause condition

---

Without Retroactive Settings:

• SLA Start → 10:30 AM (when it attached) — 45 mins of breach time already lost
• Pause → 11:30 AM (when evaluated) — 30 mins of extra time incorrectly consumed
• Breach time calculated as: 10:30 AM + 4 hrs = 2:30 PM

With Retroactive Start + Retroactive Pause:

• SLA Start → 09:45 AM (when P1 was actually set) ✅
• Pause → 11:00 AM (when On Hold was actually set) ✅
• Breach time calculated as: 09:45 AM + 4 hrs − paused time = accurate and fair

---

When to Enable vs. Avoid

✅ Enable when:

• Your SLA evaluation runs on a scheduled basis (not real-time), so there's always a gap between condition met and SLA attachment
• You have Priority-based SLAs where priority can change after creation
• You want accurate compliance reporting — especially for audits or regulatory requirements (e.g., GDPR breach notification SLAs)
• Your team uses On Hold / Awaiting Info states that should retroactively pause the clock
• You're in ITSM or HRSD where breach accountability matters

❌ Avoid when:

• Your SLA attaches in real-time via Business Rules — retroactive calculation adds unnecessary overhead
• The record's audit history is unreliable or sparse — the system won't find accurate timestamps
• You want the SLA to reflect agent response from the moment they saw it, not from a system event
• Retroactive calculation causes confusion for agents who see a breach warning on a ticket they just opened
• You have high-volume tables where audit log scanning could cause performance issues

---

Key Things to Remember

Retroactive Start and Retroactive Pause/Stop are independent settings — you can enable one without the other depending on your business need.

The accuracy of both features depends entirely on audit logs being enabled on the relevant fields (Priority, State, Assignment Group, etc.). If field-level auditing is turned off, ServiceNow has no history to look back into and the retroactive logic won't work correctly.

Both settings live in the SLA Definition record under the "Retroactive" section — always validate with a test incident before enabling in production, as they can significantly shift breach timestamps on existing open records.

---

Here's a step-by-step guide to configure and test both settings.

---

Part 1 — Configuring Retroactive Settings in SLA Definition

Step 1: Navigate to SLA Definition

• Go to Service Level Management → SLA Definitions
• Open an existing SLA or create a new one (e.g. "P1 Incident Resolution - 4 Hours")

Step 2: Set the Basic SLA Details

Field	Example Value
Name	P1 Incident Resolution - 4 Hours
Table	Incident [incident]
Type	Resolution
Duration	4 Hours
Schedule	24x7
Workflow	(your breach workflow)

---

Step 3: Define Start Condition

• Under the Start section, set:
  • Condition: Priority is 1 - Critical
  • ✅ Check "Retroactive Start"

This tells ServiceNow — "Start the clock from when Priority was first set to Critical, not from when this SLA attached."

---

Step 4: Define Pause Condition

• Under the Pause section, set:
  • Condition: State is On Hold
  • ✅ Check "Retroactive Pause"

---

Step 5: Define Stop Condition

• Under the Stop section, set:
  • Condition: State is Resolved OR Closed
  • ✅ Check "Retroactive Stop"

---

Step 6: Verify Auditing is Enabled

This is critical — without it, retroactive logic has no data to work with.

• Go to System Definition → Dictionary
• Search for table: incident, field: priority → confirm Audit is checked
• Repeat for state field
• Alternatively go to System Properties → Audit and confirm incident table auditing is on

---

Part 2 — Testing in a Dev Instance

Follow this exact sequence to validate your configuration works correctly.

Test Case Setup

Step 1: Create a new Incident

• Priority = P3 - Low
• State = New
• Note the created time (e.g. 09:00 AM)

Step 2: Wait 2–3 minutes, then change Priority to P1 - Critical

• Note this timestamp (e.g. 09:03 AM) — this is when SLA should start

Step 3: Wait another 2–3 minutes, then change State to On Hold

• Note this timestamp (e.g. 09:06 AM) — this is when SLA should pause

Step 4: Wait another 2–3 minutes, then change State back to In Progress

• Note this timestamp (e.g. 09:09 AM) — SLA should resume here

---

Step 5: Verify SLA Attached Correctly

• Scroll down on the Incident to the SLA (Task SLA) related list
• You should see your SLA record attached
• Check the following fields:

Field	Expected Value
Start Time	09:03 AM (when P1 was set) ✅
Business Time Left	Should reflect ~4 hrs minus time elapsed since 09:03
Planned End Time	09:03 AM + 4 hrs
Stage	In Progress

---

Step 6: Check Pause Was Honored Retroactively

• Open the Task SLA record (click into it from the related list)
• Look at the SLA Timeline or Pause Duration field
• The pause duration should reflect time from 09:06 AM (On Hold set) to 09:09 AM (resumed) = 3 minutes

---

Step 7: Resolve the Incident

• Change State to Resolved
• Check the Task SLA record — Actual End Time should reflect when State was set to Resolved, not when the engine evaluated it

---

Part 3 — Common Mistakes to Watch For During Testing

SLA not attaching at all? Check that your Start condition query matches exactly. Use the "Test Condition" button on the SLA Definition to validate against your test incident.

Retroactive Start not working? Most likely cause is auditing not enabled on the priority field. Go verify the dictionary entry.

Start time still showing current time instead of past? Check if another Business Rule is attaching the SLA and overriding the retroactive logic. Look in sys_script for SLA-related BRs on the incident table.

Pause duration showing zero? The state field audit may be off, or the pause condition doesn't exactly match (e.g. condition says On Hold but your State value is on_hold — check the exact value vs. label).

---

Part 4 — Useful Navigation Reference

What	Where
SLA Definitions	sla_definition.list
Task SLA records	task_sla.list
Audit History on a record	Form → Right-click header → History → Audit
Field Audit settings	sys_dictionary.list → filter by table + field
SLA Logs / Diagnostics	sla.do in URL (SLA repair tool)

---

Bonus Tip — SLA Repair Tool

If you've enabled Retroactive Start on an existing SLA Definition and want it to apply to already-open incidents, ServiceNow provides a built-in repair tool:

• URL: yourinstance.service-now.com/sla.do
• This recalculates SLA timestamps on existing open records based on audit history
• ⚠️ Always run this in dev/test first — it can shift breach times on live tickets

---

[Dr Atul G- LNG · Accepted solution]

Hi @ny424436 

https://youtu.be/1AW-_D9DZqg

https://youtu.be/X7T6fviU1hg

Here are my videos which help you to understand the same.

[Tanushree Maiti · Accepted solution]

 

Q1: What is the purpose of Retroactive Start and Retroactive Pause/Stop in SLA?

Retroactive Start
This ensures that an SLA begins from the actual past event time rather than the moment the SLA is applied.

• Without it: The SLA starts later than it should.
• With it: The SLA starts at the correct historical timestamp, reflecting when the condition was truly met.

Retroactive Pause/Stop
This ensures that an SLA pauses or stops at the exact past moment when the relevant condition changed.

• Without it: Extra, incorrect time is included in the SLA.
• With it: The SLA reflects accurate elapsed time by adjusting to the real event timing.

Refer: https://www.servicenow.com/docs/r/zurich/it-service-management?topicPivot=itsm-t_UseSLARetroactiveSt...

Q2: Under what conditions does Retroactive Start trigger, and how is the actual start time calculated?

Retroactive Start is triggered when:

• The SLA conditions are met after the actual triggering event has already occurred, and
• The SLA definition has Retroactive Start enabled (true)

Start Time Calculation:
The system looks back at the record’s history (audit data) and identifies the exact time when the SLA condition first became true. That timestamp is used as the SLA start time.

refer: https://www.youtube.com/watch?v=7mfQ69aEFHE 

          https://www.youtube.com/watch?v=DKv4LAZSH-0 

https://www.servicenow.com/community/developer-forum/what-is-retroactive-in-service-now/m-p/1771929#....

Q3: How does the system determine the correct past time for Retroactive Pause/Stop?

Retroactive Pause/Stop is triggered when:

• The pause or stop condition became true in the past,
• But the SLA engine evaluates or processes it at a later time.

refer:Understanding my SLAs Part III — Pause Times

Q4: In which real-life scenarios should these options be enabled?

Use Retroactive Start when:

• SLA conditions depend on field values set before the SLA is attached
• There are delayed or asynchronous processes, such as:
  • Integrations
  • Backdated record creation
  • Late SLA attachment
• Precise SLA timing is critical

Example:
An SLA is based on the “Assigned to group” field, but the group was set before the SLA was attached.

Use Retroactive Pause/Stop when:

• Workflow updates occur before SLA processing
• You rely on:
  • State changes (e.g., On Hold, Resolved)
  • External integrations
  • Batch updates
• Actions (like resolution) happen earlier but are processed later

Example:
A ticket is resolved through an integration, but the SLA engine processes the update afterward.

Q5: When should these options be avoided?

Avoid Retroactive Start when:

• The system handles a high volume of records (performance impact)
• When Re-opening Incidents
• SLA timing should reflect system processing time rather than actual event time

Avoid Retroactive Pause/Stop when:

• Historical accuracy is not a priority
• Simpler SLA calculations are preferred