Best Practice for Retiring SLA Definitions to survive SLA Repair?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
5 hours ago
Hi Community,
I recently ran a test in my PDI regarding the "Repair SLA" function and data preservation for retired SLAs. I wanted to share my findings and ask for advice on the long-term lifecycle of these records.
The Scenario:
We are replacing an old "P1 Resolution" SLA with a new version.
Step 1: I created a test ticket in Dev, which attached the Old SLA.
Step 2: I set the Old SLA Definition to Active = False.
Step 3: I ran "Repair SLA" on the test ticket.
The Result (Data Loss):
The existing task_sla record for the Old SLA was deleted and not replaced.
Because the definition was inactive, the Repair engine (which deletes and rebuilds from scratch) ignored it completely. This confirms that simply deactivating an SLA Definition puts historical data at risk if a repair is ever triggered on those old tickets.
The Workaround:
To prevent this, I am planning to keep the Old SLA Definition Active = True but add a "Stop Start" condition:
AND [Created] [at or before] [Date of Retirement]
This allows the Repair function to still find the definition and rebuild the historical record correctly, while preventing it from attaching to new tickets.
My Question:
If we keep these "Zombie" SLA definitions Active forever to protect historical data, we will eventually clutter the system with hundreds of legacy definitions.
What is the recommended lifecycle for finally setting them to Active = False?
Is it safe to deactivate them once all associated tickets are "Closed"?
Or is there a standard "Safe Harbor" period (e.g., 6 months post-closure) after which we can safely assume "Repair SLA" will never be run on those records again?
Thanks!
