SLA & Escalation Pack
Bugs - Status
⚙ Technical Requirements
ServiceNow scoped application / admin access
Relevant ServiceNow product/plugins for the selected pack capability
Validate in sub-production before promoting through update sets or application repository
Automation Readiness: High — The evidence clearly shows long, unpredictable resolution times, initial triage delays, and significant rework, which can be directly addressed with standard SLA definitions, flows, and PA indicators.
SLA & Escalation Pack — 5 rules
sn-sla-001
Bug Resolution SLA by Priority
SLA Definition Priority: Critical Effort: Medium
To establish and enforce resolution time targets for bugs based on their business impact, addressing the excessive and highly variable end-to-end durations observed.
Why this pack: This is a foundational SLA Definition, which is the core component for measuring and managing service level compliance.
Trigger
Bug task is created and is not yet in a resolved or closed state.
Conditions
·Active is true
·State is not one of Closed, Resolved, Done, Rejected
Actions
·Attach a Task SLA to the bug record with a duration based on Priority.
·Trigger breach warning notifications at 50% and 75% of elapsed time.
·Mark the SLA as breached if the elapsed time exceeds the defined duration.
Evidence used
·The average task duration is very high (over 2700 hours) with an extremely high standard deviation (over 3500 hours), indicating a lack of predictability.
·Sample tasks with 'Blocker' (12909305) and 'Critical' (12913993) priorities show multi-thousand-hour durations.
·The Priority field is heavily used, with 'Major', 'Critical', and 'Blocker' representing over 85% of tasks, providing a solid basis for tiered SLAs.
ServiceNow implementation
Target table
·rm_bug (or equivalent custom bug table)
Configuration area
·SLA Definition
Configuration trigger
·On create and on update (retroactive)
Configuration conditions
·Start condition: [Active] [is] [true] AND [State] [is not one of] [Closed, Resolved, Done, Rejected]
·Stop condition: [State] [is one of] [Closed, Resolved, Done, Rejected]
·Pause condition: [State] [is one of] [Blocked, Awaiting Release, Awaiting Docs]
Implementation steps
·Navigate to Service Level Management > SLA > SLA Definitions and create a new record.
·Set the Name to 'Bug Resolution SLA by Priority' and Target table to your bug table.
·Configure the Start, Pause, and Stop conditions as specified.
·Set the 'SLA definition' Type to 'SLA'.
·In the 'Duration' tab, set Duration type to 'User specified duration' and define durations based on the Priority field (e.g., Priority is Blocker: 2 business days; Priority is Critical: 5 business days; Priority is Major: 20 business days).
·Set the 'Schedule source' to 'SLA Definition' and select an appropriate business schedule (e.g., 8-5 Weekdays).
Fields used
·state
·priority
·active
Test cases
·Create a 'Blocker' bug and verify the correct SLA is attached with the shortest duration.
·Change the state of a bug to 'Blocked' and confirm the Task SLA status changes to 'Paused'.
·Change the state back to 'In Progress' and confirm the Task SLA resumes.
·Let a 'Major' bug's SLA run past its duration and confirm its status becomes 'Breached'.
Rollback notes
·Deactivate the SLA Definition record to stop it from attaching to new and updated tasks.
·Existing Task SLA records will remain but can be cancelled via a script if necessary.
Requirements / prerequisites
·Service Level Management (com.snc.sla) plugin must be active.
·A clear and consistently used 'Priority' field on the bug table.
·Defined business hours schedule in ServiceNow.
sn-sla-002
Bug Time to Triage SLA
SLA Definition Priority: High Effort: Low
To measure and reduce the time bugs spend in initial queue states before active work begins, addressing the significant delays observed at the start of the process.
Why this pack: This rule defines a response-oriented SLA, a critical control for managing initial ticket lifecycle stages and preventing backlog stagnation.
Trigger
Bug task is created in an initial intake state.
Conditions
·State is one of New, Triage, Inbox
Actions
·Attach a 'Time to Triage' Task SLA to the bug.
·Stop the SLA clock once the bug is assigned to a person or moved to an 'in progress' state.
Evidence used
·The transition 'New -> Open' takes an average of 412 hours, indicating a major delay in initial assessment.
·The rework transition 'New -> New' occurs frequently (131 times) and averages 527 hours, showing tasks are stagnating in the 'New' state without action.
·Multiple intake states exist ('New', 'Triage', 'Inbox'), highlighting the need for a standardized response time metric.
ServiceNow implementation
Target table
·rm_bug (or equivalent custom bug table)
Configuration area
·SLA Definition
Configuration trigger
·On create
Configuration conditions
·Start condition: [State] [is one of] [New, Triage, Inbox, Backlog]
·Stop condition: [State] [is not one of] [New, Triage, Inbox, Backlog] OR [Assigned to] [is not] [empty]
Implementation steps
·Navigate to Service Level Management > SLA > SLA Definitions and create a new record.
·Set the Name to 'Bug Time to Triage' and Target table to your bug table.
·Configure the Start and Stop conditions as specified. Do not configure Pause conditions.
·Set a business duration, e.g., 4 business hours for all priorities, to ensure timely review.
·Set the Schedule to an appropriate business schedule.
Fields used
·state
·assigned_to
Test cases
·Create a new bug in the 'New' state and verify the SLA attaches.
·Assign the bug to a user and verify the SLA stops.
·Change the bug's state from 'Triage' to 'Open' and verify the SLA stops.
Rollback notes
·Deactivate the SLA Definition record.
Requirements / prerequisites
·Service Level Management (com.snc.sla) plugin must be active.
sn-sla-003
Resolution SLA Breach Warning Flow
Flow Designer Priority: High Effort: Medium
To proactively notify assignees and managers when a high-priority bug is at risk of breaching its resolution SLA, enabling intervention to mitigate delays.
Why this pack: This is a direct escalation action based on SLA elapsed percentage, a core capability for proactive service level management.
Trigger
A 'Resolution SLA' Task SLA record's 'Percentage' field reaches 50% or 75%.
Conditions
·Task SLA.SLA Definition is 'Bug Resolution SLA by Priority'
·Task SLA.Stage is not 'Breached' or 'Completed'
·Task SLA.Task.Priority is one of 'Blocker', 'Critical'
Actions
·At 50% elapsed: Post a work note on the associated bug, tagging the assignee.
·At 75% elapsed: Send an email notification to the assignment group manager.
Evidence used
·The standard deviation of task duration is extremely high (e.g., 3516.34 hours), indicating poor predictability and frequent unexpected delays.
·The process involves many steps and handoffs (e.g., 'New -> To Do -> In Progress -> Ready for Review -> Done -> Closed'), increasing the risk of tasks stalling without visibility.
ServiceNow implementation
Target table
·task_sla
Configuration area
·Flow Designer
Configuration trigger
·Updated: task_sla record
Configuration conditions
·[SLA Definition] [is] [Bug Resolution SLA by Priority]
·[Stage] [is not one of] [Breached, Completed, Cancelled]
·[Percentage] [changes]
Implementation steps
·Create a new Flow in Flow Designer.
·Set the Trigger to 'Record Updated' on the 'Task SLA' [task_sla] table.
·Add a filter condition: [SLA Definition] is 'Bug Resolution SLA by Priority' and [Percentage] changes.
·Add a 'Look Up Record' step to get the associated Bug record from the 'Task' field.
·Add an 'If' flow logic block for: '[Task SLA Record -> Percentage] [is] [75]'.
·Inside the 'If', add an action 'Send Email' to the '[Bug Record -> Assignment Group -> Manager]'. Include bug details in the email body.
·Add an 'Else If' flow logic block for: '[Task SLA Record -> Percentage] [is] [50]'.
·Inside the 'Else If', add an action 'Add Work Note' to the '[Bug Record]'. The note should state: 'SLA has reached 50%. Please review to ensure timely resolution. @[Bug Record -> Assigned To]'
·Activate the Flow.
Fields used
·task_sla.percentage
·task_sla.sla
·task_sla.stage
·task_sla.task
·rm_bug.assignment_group
·rm_bug.assigned_to
·rm_bug.priority
Test cases
·Create a bug with the Resolution SLA and a short duration (e.g., 10 minutes).
·Wait for 5 minutes and verify a work note is added to the bug.
·Wait for 7.5 minutes and verify an email is sent to the group manager.
Rollback notes
·Deactivate the Flow in Flow Designer.
Requirements / prerequisites
·Flow Designer (com.glide.hub.flow_designer) plugin must be active.
·The Bug Resolution SLA (sn-sla-001) must be implemented first.
sn-sla-004
Stagnant Bug in Queue State Follow-up
Flow Designer Priority: Medium Effort: Medium
To automatically detect and prompt action on bugs that are stalled in initial queue states for an extended period, preventing them from becoming 'lost' in the backlog.
Why this pack: This automation acts as a proactive aged-task escalation, a common SLA-related control to ensure tickets do not fall through the cracks and eventually breach their overall resolution SLA.
Trigger
Scheduled to run daily.
Conditions
·Bug is Active
·State is one of New, Triage, Inbox, Backlog, Open
·Updated more than 5 business days ago
Actions
·Add a work note to the bug task prompting the assignment group for an update.
Evidence used
·The 'New -> New' self-loop transition has an average duration of 527.34 hours (over 21 days), indicating tasks are aging significantly without any state change.
·The average time for 'New -> Open' is 412.84 hours (over 17 days), reinforcing that tasks are sitting idle for long periods before being worked.
ServiceNow implementation
Target table
·rm_bug (or equivalent custom bug table)
Configuration area
·Flow Designer
Configuration trigger
·Daily at a scheduled time (e.g., 8:00 AM)
Configuration conditions
Implementation steps
·Create a new Scheduled Flow.
·Set the trigger to run daily.
·Add a 'Look Up Records' action on the bug table.
·Set the conditions: [Active] [is] [true] AND [State] [is one of] [New, Triage, Inbox, Backlog, Open] AND [Updated] [relative] [on or before] [5 business days ago].
·Add a 'For Each' loop to iterate through the found records.
·Inside the loop, add an 'Add Work Note' action to the 'Current Item'.
·The work note should say: 'This bug has not been updated in over 5 business days. Please review and provide an update or advance its state.'
·Activate the Flow.
Fields used
·state
·active
·sys_updated_on
Test cases
·Create a bug and leave it in the 'New' state. Manually set its 'Updated' date to 6 days in the past. Run the flow and verify a work note is added.
·Update the same bug. Run the flow again and verify no new work note is added.
Rollback notes
·Deactivate the scheduled flow in Flow Designer.
Requirements / prerequisites
·Flow Designer (com.glide.hub.flow_designer) plugin must be active.
sn-sla-005
PA Indicator for Reopened Bugs
Performance Analytics Priority: Medium Effort: Low
To measure and track the volume of bug rework over time. This provides visibility into quality issues that lead to resolution delays and repeat SLA breaches.
Why this pack: Tracking rework is crucial for SLA management as it directly impacts resolution times and customer satisfaction. This PA indicator provides the metric needed to manage and reduce rework, improving overall SLA performance.
Trigger
PA data collection job runs daily.
Conditions
·Bug's 'reopen_count' field is greater than 0, OR a Metric Definition captures a change to a 'Reopened' state.
Actions
·Collect daily count of reopened bugs.
·Display trend on a dashboard, broken down by Assignment Group and Project.
Evidence used
·The 'Closed -> Reopened' transition occurred 65 times, which is a direct measure of failed resolutions.
·The overall process has a high rework percentage, consistently between 21% and 24%.
·Variant 'New -> New -> Open...' shows a rework loop at the start of the process.
ServiceNow implementation
Target table
·rm_bug (or equivalent custom bug table)
Configuration area
·Performance Analytics
Configuration trigger
·Daily PA data collection
Configuration conditions
·Indicator Source: Table is the bug table, Conditions: [Reopen count] [greater than] [0]
Implementation steps
·Ensure the bug table has a 'Reopen count' field that increments when a bug is moved from a closed/resolved state to an open one. If not, create a business rule to manage this field.
·Navigate to Performance Analytics > Indicators > Automated Indicators and create new.
·Name: 'Number of reopened bugs'.
·Select an Indicator Source based on the bug table with a condition '[Reopen count] [>] [0]'. If one doesn't exist, create it.
·Set 'Aggregate' to 'Count'.
·Direction should be 'Minimize'.
·Add this indicator to a PA job for daily collection.
·Create breakdowns for this indicator using existing 'Assignment Group' and 'Project' breakdowns.
·Add a time series widget for this indicator to a relevant dashboard.
Fields used
·reopen_count
·assignment_group
·project
Test cases
·Reopen a closed bug, ensuring the 'reopen_count' increments.
·Run the PA data collection job for that indicator.
·Check the Analytics Hub or dashboard widget to see if the score for the current day increased by one.
Rollback notes
·Deactivate the Automated Indicator record.
·Remove the indicator from the PA data collection job.
Requirements / prerequisites
·Performance Analytics (com.snc.pa) plugin must be active.
·A field such as 'reopen_count' on the bug table, or a metric definition to track state changes to 'Reopened'.