Hard Difficulty Questions

UI Actions on the Incident table

Why it fails: UI actions control form buttons and client behaviour on the Incident table, not how community posts are indexed or ranked. It is tempting because UI actions legitimately customise incident record interactions, which would be the correct configuration when administrators need to alter incident form behaviour.

Dictionary search flags on the task table

Why it fails: Dictionary search flags apply to task-table text indexing, not community content relevance. It is tempting because dictionary flags genuinely improve search on task records by controlling which terms are indexed, which would be the right configuration for poor task search results, not community posts.

Email notification templates

Why it fails: Email notification templates govern outbound messages, not search indexing or ranking of community content. It is tempting because templates are the right configuration when users must be alerted about community activity, such as replies or mentions, rather than when search results return stale posts.

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.

kb_knowledge

Why it fails: Incorrect. kb_knowledge is strictly for knowledge base articles.

sn_customerservice_case

Why it fails: Incorrect. This is the case table, not the community content table.

sys_user

Why it fails: Incorrect. This table stores user records.

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.

Delete all search sources and rely entirely on global text search

Why it fails: Incorrect. Global text search is legacy and deleting search sources breaks case deflection.

Add a client script to hide search results in the browser DOM

Why it fails: DOM manipulation is insecure because the underlying data is still transmitted to the client.

Disable Contextual Search globally during business hours

Why it fails: Incorrect. Disabling search defeats the purpose of case deflection.

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.

Configure SLA Workflow Retroactive Pause parameters

Why it fails: Retroactive pause handles time adjustments during pause periods rather than case reopening mechanics.

Set the Retroactive start checkbox on the SLA definition and define appropriate reset conditions

Why it fails: Retroactive start calculates the elapsed time from a past date, but does not inherently govern the creation of a brand new instance upon reopening without reset rules.

Modify the 'com.snc.sla.engine.version' system property to legacy mode

Why it fails: Changing engine versions is not a recommended troubleshooting step for controlling SLA lifecycle rules on reopening.

The system property com.glide.sla.pause_enabled is set to false.

Why it fails: No such global property exists to globally disable pauses in this manner.

The Task SLA table has read-only ACLs preventing the state update.

Why it fails: ACLs block user UI updates, not backend SLA engine state transitions.

The case automatically closes

Why it fails: Resolving a problem does not cascade a state change to linked cases; the case retains its current state until an agent updates it manually. Automatic closure applies to child tasks or incidents resolved through workflow rules, not problem-to-case linkage, so this option misreads the default behaviour the question tests.

The case is moved to 'Pending'

Why it fails: Linking a case to a problem does not set the case State to Pending; that state reflects awaiting customer response. Pending is correct when a case waits on the caller, not when an associated problem is resolved.

The case is moved to 'Work in Progress'

Why it fails: Work in Progress indicates active investigation by an agent, which resolution of a linked problem does not trigger. This state applies while an agent is actively working the case, not as the default outcome of problem resolution.

The system will throw a severe security exception due to table-level ACL restrictions.

Why it fails: Table-level ACLs apply equally to scripted inserts and engine-generated ones, so no severe security exception occurs. It is tempting because ACLs do govern table access, but the actual consequence is bypassing the SLA engine's condition evaluation and breach-time calculation, producing inconsistent SLA records.

Dictionary overrides on the task_sla table will fail to load.

Why it fails: Dictionary overrides on task_sla load independently of record origin, so manual inserts do not break them. It is tempting because dictionary overrides are a genuine platform feature, but the real risk is bypassing the SLA engine's condition evaluation and breach-time calculation, leaving inconsistent SLA state.

The scheduled job processor will immediately delete the manually inserted record.

Why it fails: No scheduled job deletes manually inserted task_sla records; the job processor only runs SLA processing logic. It is tempting because scheduled jobs do maintain SLA records, but manual insertion bypasses the engine's condition matching and breach-time calculation, not triggering deletion.

Automatically inheriting problem work notes into customer-facing case comments

Why it fails: Problem work notes are internal and are not copied into customer-visible case comments; case comments are authored separately to control what customers see. Inheriting notes would suit internal knowledge sharing, but CSM keeps customer-facing communication distinct from problem investigation records.

Automatically purging all linked cases from the database immediately

Why it fails: Linking a case to a problem never deletes case records; cases retain their own lifecycle and history for audit and reporting. Purging is tempting when cleaning stale test data, but that is a separate administrative deletion task, not a linking behaviour.

Writing custom business rules to calculate payroll bonuses

Why it fails: Gamification setup uses CSM's built-in points, badges and reputation configuration, not custom business rules for payroll. Business rules automate record calculations such as HR or finance workflows; they would be the right tool for computing employee bonuses, which is unrelated to community engagement scoring.

Changing core database engine settings to InnoDB

Why it fails: Gamification and reputation management are configured through community UI settings, badges, points and reputation rules, not database engine internals. InnoDB is MySQL's storage engine, relevant when tuning a self-hosted database's transactional performance, not when enabling community engagement features in CSM.

Data Policy

Why it fails: Data Policies enforce field validation and mandatory values on a form; they cannot generate approval tasks. They suit ensuring data quality at entry, whereas the requirement demands server-side record-triggered creation of an approval record when a contact is inserted.

Client Script

Why it fails: Client Scripts run only in the browser during form interaction, so they cannot reliably create approval tasks for contacts inserted via imports, APIs or background processes. They suit real-time form validation or UI behaviour, not server-side record-triggered automation.

Account Tier business rule

Why it fails: An Account Tier business rule fires on the Account table, not on Contact creation, so it never triggers when a new contact is inserted. Business rules suit enforcing logic on the table they run against; here the trigger record is the Contact, not the Account.

Reset the system

Why it fails: Not a valid action.

Delete the major case record

Why it fails: Destructive actions are not supported.

Child cases remain unchanged until the agent manually updates them.

Why it fails: Child cases inherit the primary case's state automatically, so no manual agent update is needed; leaving them unchanged desynchronises the hierarchy. Manual updating is tempting because agents do edit child cases directly for their own fields, which is correct for case-specific data but not for inherited state.

Child cases are automatically closed.

Why it fails: A state change on the primary propagates the new state to child cases rather than closing them; closure requires its own resolution workflow. Automatic closure is tempting because it sounds like tidy cascade behaviour, and it would be right if the requirement were bulk-closing every linked case at once.

Child cases are detached from the Major Case.

Why it fails: Detaching child cases breaks the Major Case hierarchy, so roll-up reporting and inherited state changes stop working; child cases stay linked and inherit the primary's state. Detachment is genuinely used when a child case must be managed independently of its parent, not during a routine state change.

Business Rules on the Case table

Why it fails: Business Rules on the Case table run server-side logic on insert or update and can create related records, but linking a problem to a case requires the specific case-to-problem relationship handling that this scenario's automation demands elsewhere.

Client Scripts on Case Form

Why it fails: Client Scripts execute in the browser on the Case form, so they only fire when a user interacts with the form and cannot run for cases created via API, email, or import. They suit dynamic form behaviour such as field visibility.

Case Action Assignment Rules

Why it fails: Case Action Assignment Rules assign or route cases to users or groups based on conditions; they do not create related problem records. They are correct when the requirement is automatic case ownership or assignment rather than record generation.

Enable legacy CMS site parameters in System Properties

Why it fails: Automated article suggestions rely on the Knowledge Management advanced plugin and its suggestion configuration, not on legacy CMS site properties, which govern deprecated CMS content delivery. It is tempting because CMS and knowledge both surface articles, so administrators assume shared parameters, but legacy CMS settings are irrelevant to Agent Workspace suggestions.

Write a custom business rule on kb_knowledge to push suggestions via WebSockets

Why it fails: Suggestions are delivered through the platform's built-in knowledge suggestion framework, which polls configured sources; no custom WebSocket business rule on kb_knowledge is required or supported. It is tempting because real-time push feels necessary for responsiveness, which would be the right approach for bespoke live notifications outside the standard framework.

Modify the global UI macro named 'kb_suggestion_widget'

Why it fails: Automated article suggestions rely on the knowledge base search configuration and the agent workspace settings, not on editing a global UI macro; the kb_suggestion_widget macro controls rendering, not suggestion logic. It would be correct only when customising the widget's visual presentation or layout.

SLA Workflow [sla_workflow] table for analyzing workflow canvas execution durations.

Why it fails: The SLA Workflow table stores workflow canvas definitions and execution metadata, not the timer events or breach records SLA reporting needs. It is tempting because workflow execution durations sound SLA-related, yet comprehensive reporting draws on task SLA and SLA breach tables instead.

Sys Audit [sys_audit] table for tracking every second elapsed on active SLA timers.

Why it fails: Sys Audit records field-level configuration changes, not elapsed SLA timer seconds; active timer state lives in task SLA records. It is tempting because audit trails appear authoritative and time-stamped, but sys_audit tracks who changed what, not how long an SLA timer has been running.

An ACL restriction

Why it fails: An ACL restriction only controls record-level read, write, and delete permissions; it cannot set case status or send notifications when credit status changes. It is tempting because ACLs are the correct tool when you need to limit which users or teams can access specific account records.

A Data Policy on the Account table

Why it fails: A Data Policy enforces field-level security or masking on the Account table; it cannot trigger case updates or notifications. It is tempting because policies govern data access rules, which would be the right choice when restricting which fields or records users may read.

A client script on the Case form

Why it fails: A client script runs only in the browser on the Case form, so it cannot react to a credit-status change on the Account record or update unrelated open cases. It is tempting because client scripts handle form behaviour, but this automation requires a business rule or server-side logic triggered by the Account update.

Client Scripts on the Case form

Why it fails: Client scripts run in the browser and can be bypassed, so they cannot enforce a role-based transition restriction reliably. They are tempting because they govern form behaviour, and would be correct for cosmetic field visibility or validation rather than authoritative lifecycle control.

Dictionary Overrides on the State field

Why it fails: Dictionary overrides change field-level behaviour such as mandatory or read-only state, not which transitions a role may perform. They are tempting because they do constrain the State field, and would be correct if the requirement were to make State read-only for certain users.

Assignment Rules table configuration

Why it fails: Assignment Rules assign records to owners or queues; they cannot gate a state transition on role membership. The tempting fit is that they govern case routing, so they would be correct for automatically assigning new cases to a team, not for enforcing a role-restricted lifecycle transition.