CCNA Service Level Agreements Questions

Reaching the breach threshold triggers the SLA engine to write 'Breached' into the Task SLA record's Stage field, satisfying the automatic state transition the question demands. Stage is the engine-managed lifecycle value, so no user action is needed for this update to occur.

On re-opening, the SLA engine re-evaluates start conditions; if they are met again, it creates a fresh Task SLA instance rather than resuming the prior one. This satisfies the stem's scenario by generating new SLA tracking for the reopened Case.

When no schedule is set on the SLA Definition, the engine treats all calendar time as working time, effectively a 24x7 schedule. This means weekends and holidays count toward breach. Implementers must explicitly attach a schedule when business hours should be honored, otherwise targets are measured in calendar time.

Task SLAs are attached to the Case as related records, and the Task SLA related list on the Case form displays each SLA's stage, elapsed percentage and breach timers in real time, letting the agent monitor active commitments without leaving the record.

SLA Definition records hold the schedule, conditions and workflow that enforce resolution targets, and its pause condition and target fields calculate the time allowed against case priority. This satisfies the stem's requirement for the record type defining resolution time per priority, rather than the task-level SLA or entitlement records.

The Schedule field on the SLA Definition record accepts a predefined business schedule, letting the SLA inherit that schedule's time zone and working hours. This satisfies the stem by applying a custom schedule without writing code or creating a schedule source.

Task SLA [task_sla] is the default table storing both active and historical SLA instances attached to customer service cases, satisfying the requirement for a single table covering current and past records. Case SLAs are task-based, so their instances reside here rather than in the contract_sla definition table.

A custom business rule that inserts Task SLA records directly duplicates the work of the SLA background engine, which already evaluates SLA Definitions and attaches SLAs. Both paths create separate Task SLA records for the same case, producing duplicate attachments.

The Task SLAs related list surfaces attached SLA records and their stage and remaining time directly on the task form, while the workspace SLA component renders the same countdown data in CSM Workspace. Both display live SLA timers without custom portal code.

The Task SLA table tracks the actual progress, stage, and breach status for each task instance.

SLA stages are stored as records in the SLA Stages [sla_stage] table and referenced by the stage choice field on Task SLA records. Modifying display therefore means editing those stage definitions or the choice list, which is where CSM case SLA stage presentation originates.

The Retroactive field makes the SLA engine calculate elapsed time from the exact moment the Case was created, even when the SLA definition was authored afterwards. Without it, timing begins only when the SLA is attached, so the stem's backdated-start requirement fails.

Performance Analytics indicators aggregate scores over time and support breakdowns, so an SLA compliance indicator broken down by agent and grouped monthly displays the required percentage directly. Standard reports cannot compute this time-series compliance percentage as cleanly.

The Reset condition terminates the current SLA instance and starts a fresh one, restarting the timer from zero. This differs from Pause, which halts the clock but resumes the same instance, and from Stop, which ends it permanently without renewal.

The Start condition field holds the filter criteria that determine which Case records enter the SLA workflow, so scoping it to Priority equals High and Account VIP status ensures the agreement applies only to those records.

The Table field on an SLA Definition determines which task table the engine evaluates. If it is set to a table other than the Case table, the definition never attaches to cases regardless of how correct the conditions and schedule are. Verifying this field is the first logical troubleshooting step when an SLA does not attach.

SLA Definitions support warning and breach notifications, and the SLA engine raises corresponding events that workflows and notifications can consume. Configuring the warning threshold and breach notification on the definition, or handling the breach event in a workflow, delivers emails at the correct times without custom polling. This is the supported, maintainable approach.

SLA escalation demands timely human awareness when a breach or warning threshold fires. The notification activity delivers templated emails to managers or support groups, satisfying the stem's requirement to handle escalation notifications within the workflow rather than merely logging the breach.

The SLA Definition record carries the schedule and time zone fields that determine which support hours apply, letting each regional centre's operating hours drive its own SLA calculations. This satisfies the requirement for region-specific operating hours.

Mismatched display labels vs. backend choice values (e.g., 'Awaiting Info' vs 'awaiting_info') will prevent condition evaluation.

Modern SLA notifications are configured declaratively against percentage thresholds, so simple percentage-based email alerts need no workflow graph. This satisfies the stem's maintenance constraint: where only straightforward alerts are required, the notification feature avoids the overhead of building and maintaining full workflow logic.

The Pause condition stops the SLA duration timer while the case is in the Awaiting Customer state, and the Resume condition restarts it once the case re-enters a work-in-progress state. This is exactly the pause/resume behavior the manager requires, keeping elapsed SLA time from accruing during customer-wait periods.

Task SLA [task_sla] records each SLA instance against a task, storing the stage, breach time and duration fields needed to calculate averages. Because tasks carry the Account reference, grouping resolution-stage records by Account yields the average Resolution SLA duration the manager requires.

The Pause condition is designed to temporarily halt the SLA timer without ending the SLA. By pausing when the case enters Awaiting Customer or Awaiting Problem states, the timer stops counting during those periods and resumes when the case leaves those states. The Stop condition on Closed correctly ends the SLA when the case is resolved and closed.

Workflow Notification activities fire on SLA stage transitions, such as entering an escalated or breached stage, sending alerts before the breach completes. This uses the workflow engine's stage-driven triggers, satisfying the requirement to notify stakeholders ahead of an SLA breach.

The SLA engine evaluates Pause and Resume conditions against the task record to temporarily stop the timer without ending the SLA. Setting Pause to the 'Awaiting Customer' state and Resume to any other state causes the timer to hold while waiting on the customer and restart when the case is no longer in that state, preserving elapsed time toward breach.

The SLA Definition record's Schedule field references a schedule record containing the business hours and time zone. Attaching that schedule makes duration calculation count only defined business hours instead of continuous 24x7 time, satisfying the business-hours constraint.

The Start condition determines when the SLA attaches to a task. By adding a condition to exclude cases where the case type is 'Internal', the SLA engine will not attach the SLA to those cases at all. This is the correct approach because the Start condition is evaluated when the task is created or updated, and if it evaluates to false, no SLA instance is created.

The SLA engine generates Task SLA records with calculated start, pause, stop and breach times, drives stage progression, and attaches the workflow. Inserting records manually bypasses that schedule calculation and stage logic, leaving SLAs that never transition or trigger correctly.

The task_sla table stores per-task SLA records, so it exposes actual elapsed runtime against defined targets, breach occurrences, and the resulting compliance percentage. That directly satisfies the stem's demand for metrics covering durations, breach counts, and compliance, which no configuration or definition table provides.

The Target field determines which SLA timer the definition governs, such as Resolution or Response, and sets the metric objective type the engine evaluates. Setting it to Resolution means the definition only attaches to resolution-based timers.

The Schedule field on an SLA Definition references a business schedule that defines working hours and holidays. The SLA engine uses that schedule to calculate business elapsed time, so only time within the contracted support hours counts toward the SLA target. This directly satisfies the requirement to exclude nights, weekends, and holidays.

The Table field is mandatory because an SLA Definition must bind to a specific task table, such as the Case table, to know which records it evaluates. Without this target, the SLA engine cannot attach conditions or schedules, so ServiceNow blocks saving the definition until a table is selected.

The Task SLA [task_sla] table stores each running SLA instance against a task, so any runtime adjustment — pause, restart, or recalculated breach time — is written there, satisfying the requirement to audit changes to runtime instances rather than definitions.

The Pause condition on the SLA Definition determines when the SLA timer halts. Adding a condition matching State is Awaiting Problem pauses the running SLA, so it no longer accrues duration while the case sits in that state.

SLA Definitions are separate records, each with its own start conditions and duration. Referencing the Account Tier field in each definition's start condition lets the correct SLA attach based on tier, satisfying the requirement for tier-dependent durations without scripting.

The Start condition should trigger when the case is assigned to the specific group, as that is when the SLA timer should begin. The Stop condition should trigger when the case state becomes Closed, as that is when the SLA timer should end. This aligns with the business requirement and uses the appropriate condition types.

Completed marks the stage where the SLA's stop condition has been satisfied ahead of the breach time, halting the SLA timer. Unlike breached, which triggers when the breach time passes without resolution, completed confirms the task met its stop condition within the allotted window, directly satisfying the stem's requirement.

The 'Schedule' field on the SLA definition determines which schedule is used to calculate elapsed time. By setting it to 'Business Hours', the SLA engine will only count time within the defined schedule periods. The 'Schedule source' field indicates where the schedule comes from; setting it to 'SLA definition' means the schedule specified on the SLA definition is used, which is correct for this scenario. This ensures the SLA pauses outside business hours as required.

Reset conditions recalculate an SLA's timeline when a specified field changes, so switching priority from Medium to Critical restarts the attached SLA against the shorter critical duration. This satisfies the stem's requirement that the existing SLA reflect the new critical target rather than continuing on the original timeline.

Every active task record is repeatedly evaluated against start, stop, pause and reset conditions, so condition complexity and evaluation frequency drive engine load directly. More conditions and more frequent checks multiply the calculation work in high-volume environments.