Service Level Agreements practice questions

Case [sn_customerservice_case]

Why it fails: While Case extends Task, SLA Definitions are created on the Task SLA [sow_sla] or SLA Definition [contract_sla] table, which uses Task as the base table to evaluate extended tables.

SLA Definition [contract_sla]

Why it fails: Contract SLA is the table where the definition record itself is stored, not the base table targeted by the SLA condition.

Customer Account [customer_account]

Why it fails: The Customer Account table is not a task-based table and cannot support task SLAs natively without custom relationships.

In a Business Rule running on the Task SLA table

Why it fails: Custom business rules on Task SLA are discouraged for native pause logic, as the SLA engine handles this out of the box.

In the SLA Workflow using a Timer activity

Why it fails: Timers in workflows are for delays, not for managing the internal Pause state of the Task SLA engine.

In the SLA Definition record using the Pause condition field

Why it fails: Wait, the pause condition is configured directly on the SLA Definition record. Let's check option D.

Customer SLA

Why it fails: Customer SLA is not a standard native SLA type classification in ServiceNow.

Resolution SLA

Why it fails: Resolution SLAs measure the time from creation to resolution/closure.

Operational SLA

Why it fails: Operational SLAs define agreements between internal departments, not primary case metrics.

SLA Properties set in Service Level Management properties

Why it fails: Global SLA properties define general engine behavior, not specific 75% warnings for individual definitions.

SLA Workflow with a Workflow Timer set to 75%

Why it fails: SLA workflows can be attached, but percentage-based triggers are typically handled using SLA Percentage or Breach stages.

Data Policy enforcing notification fields at 75%

Why it fails: Data policies enforce mandatory and read-only states, not workflow notifications.

The system automatically cancels the Response SLA breach when the Resolution SLA is met.

Why it fails: Meeting one SLA does not retroactively cancel the breach state of a different completed SLA.

The Case indicator remains normal because the Resolution SLA was met.

Why it fails: A breach on any attached SLA typically causes the task's SLA indicator to show breached.

The SLA engine deletes the Response SLA record to keep reporting clean.

Why it fails: SLA records are preserved for auditing and reporting purposes and are never automatically deleted upon resolution.

They are deleted from the database immediately.

Why it fails: SLA records are never deleted upon task cancellation; their state is updated to Cancelled for auditing.

They remain paused indefinitely.

Why it fails: Cancellation terminates the lifecycle rather than leaving them in a perpetual paused state.

They continue running until they reach their breach time.

Why it fails: Running SLAs on a cancelled task are terminated to prevent false breaches.

sn_customerservice_manager

Why it fails: Managers oversee cases and reports but do not inherently have SLA configuration rights without specific admin roles.

sn_customerservice_agent

Why it fails: Agents handle cases, not SLA definition setups.

itil

Why it fails: The ITIL role is for ITSM processes and does not grant CSM SLA definition management.

Reset condition

Why it fails: Reset conditions restart the SLA lifecycle entirely.

Pause condition

Why it fails: Pause conditions temporarily halt the timer without completing the SLA.

Start condition

Why it fails: Start conditions determine when the SLA begins tracking.

Notification activity with incident payload mapping

Why it fails: Notification activities send emails; they do not generate database records.

SLA Breach Action business rule

Why it fails: There is no native business rule named 'SLA Breach Action'.

Run Script activity using current.insert() on the Incident table

Why it fails: While possible, using raw script in workflows is less maintainable than native workflow activities like Create Task.

Delete the SLA Definition before making updates

Why it fails: Deleting definitions breaks historical reporting and active SLA linkages.

Disable the SLA background worker thread

Why it fails: Disabling background workers stops all SLA processing globally.

Lock the Task SLA table using Access Control Lists (ACLs)

Why it fails: ACLs control security read/write, not engine calculation behavior.

All matching SLAs attach simultaneously, creating multiple competing timers.

Why it fails: While multiple SLAs can attach, precedence or specific conditions prevent overlapping conflicts based on definition configuration.

The system prompts the user to select the correct SLA during case creation.

Why it fails: SLA attachment is entirely automated by the backend engine.

ServiceNow processes SLAs alphabetically by name.

Why it fails: Alphabetical processing is not used for SLA precedence.

Use a Workflow timer activity with a dynamic script.

Why it fails: SLA durations are established at the definition level, not via workflow timers.

Create a client script that calculates the milliseconds and injects them into the SLA engine.

Why it fails: Client scripts cannot interface with the backend SLA calculation engine directly.

Write an After Insert business rule that modifies the duration field on the contract_sla table.

Why it fails: Modifying the contract_sla table dynamically per case violates multi-tenant/definition architecture.

The Task SLA table has duplicate dictionary entries.

Why it fails: Dictionary entries do not cause duplicate workflow execution.

The background worker job is scheduled to run twice every minute.

Why it fails: Running job frequencies affect timing, not duplication of workflow execution paths.

The Case table business rules are firing recursively.

Why it fails: Recursive business rules usually cause stack overflows, not specific SLA workflow duplication.

Modify the Service Portal widget script to attach the SLA manually.

Why it fails: Manual portal attachment bypasses standard SLA engine management.

Use Data Policies to block SLAs on non-portal channels.

Why it fails: Data policies control form fields, not SLA attachments.

Create an inbound email action to delete SLAs for email cases.

Why it fails: Deleting SLAs post-creation is poor practice compared to filtering them out at definition start conditions.

Yes, by attaching two conflicting workflows simultaneously.

Why it fails: Conflicting workflows cause erratic behavior and do not alter schedule calendar math.

Yes, by checking the 'Dual Schedule' checkbox on the Task SLA form.

Why it fails: There is no 'Dual Schedule' checkbox in ServiceNow.

Yes, by configuring separate schedules in the Advanced SLA property table.

Why it fails: System properties do not support split schedules per SLA state.

Manually update every past task_sla record using a background script.

Why it fails: While a script can fix past data, ensuring proper engine behavior for cancellation handles future cases.

Delete all breached records from the task_sla table.

Why it fails: Deleting records destroys audit trails.

In the Service Level Management Properties module under 'Custom Stages'.

Why it fails: SLM properties do not manage custom UI/engine stages directly.

In the Dictionary Override of the Case table.

Why it fails: Task SLA stages belong to the Task SLA table, not the Case table.

In the SLA Definition condition builder as an explicit stage filter.

Why it fails: Condition builders filter records; they do not define global engine stages.

Delete the Task SLA table dictionary entry for maintenance records.

Why it fails: Dictionary entries apply globally to tables, not individual records.

Disable the SLA engine for the maintenance user profile.

Why it fails: Users do not have SLA engine toggles on profiles.

SLA workflows automatically modify the base duration of the Task SLA record upon completion.

Why it fails: Workflows cannot alter the base duration of an already running task SLA instance.

SLA workflows run synchronously on the client browser before the form saves.

Why it fails: Workflows execute entirely on the server side in the background.

Hardcoding regional holidays into client-side UI policies for each agent.

Why it fails: Holidays must be handled server-side via calendar schedules, not UI policies.

Changing the global system language property to match the region.

Why it fails: Language properties affect translation, not calendar holiday schedules.

Using Data Policies to enforce regional timezones on the Case form.

Why it fails: Data policies do not handle schedule calendar math.