Troubleshooting Scenario Questions

Conflict detection requires an interactive web browser session

Why it fails: Business rules execute server-side on the Glide stack regardless of client, so a browser session is never a precondition for conflict detection during REST calls. It is tempting because interactive conflict detection does surface in the UI, and requiring a session would be the correct condition for client-side UI actions or form-based validation.

REST APIs inherently disable all database business rules globally

Why it fails: REST APIs invoke the same server-side business rule engine as the UI, so no global disabling occurs; rules run unless a condition, filter, or ACL blocks them. It is tempting because API calls do bypass UI policies and client scripts, which is the correct scenario for assuming certain logic will not fire.

Integration accounts lack read access to the cmdb_ci table

Why it fails: Conflict detection rules are skipped when the updating user is the integration account, because the rule's condition excludes the session user from triggering. Integration accounts lacking read access to cmdb_ci is a permissions issue, not a conflict-detection bypass. Read access matters for data retrieval, not rule execution.

Quick Messages

Why it fails: Quick Messages are canned responses inserted into the activity stream or comments, not into multiple incident form fields. They are tempting because they provide predefined standard text for common issues, and would be correct when an agent needs to add a reusable written response to a customer conversation.

Data Policies

Why it fails: Data Policies enforce field mandatory, read-only or default-value rules on records; they do not insert reusable blocks of standard text. They are tempting because they govern field behaviour at the platform level, and would be correct when the requirement is to force or restrict field entry rather than supply canned wording.

Catalog Client Scripts

Why it fails: Catalog Client Scripts run JavaScript on catalog item forms, not incident records, so they cannot inject predefined text into incident fields. They are tempting because they dynamically populate and validate variables during service catalogue ordering, which is the correct choice when building request forms rather than handling agent-entered incidents.

The browser cache needs clearing

Why it fails: Browser cache clearing affects client-side rendering, not server-side workflow engine execution or timer persistence. The timer fails because the legacy engine does not persist timer state across restarts. Cache clearing is tempting when users see stale UI after changes, which would be the correct fix for display issues, not engine resume failures.

The user session expired

Why it fails: An expired user session does not halt timer activities, because timers resume through the workflow engine's scheduler independently of interactive sessions. It is tempting since session expiry commonly breaks user-driven actions, but legacy engine timers fail to resume after restart when the timer records are not persisted or recovered.

The Problem form layout was modified

Why it fails: Form layout changes affect presentation only, not workflow engine state persistence. The timer fails because the legacy engine does not persist timer state across restarts, so it cannot resume. Layout modification is tempting as a suspected cause of workflow misbehaviour, but it would be relevant only when fields or UI elements fail to display correctly.

Service Catalog workflow versioning rules

Why it fails: Service Catalog workflow versioning governs request fulfilment approval, not CI relationship traversal, so it cannot influence conflict detection. It is tempting because both are ServiceNow configuration areas, and would be correct when controlling which catalogue item versions remain orderable.

Incident management priority lookup tables

Why it fails: Conflict detection traverses CI relationships using the CI class relationship rules, the CI relationship type definitions, and the identification/reconciliation engine's traversal configuration — not incident priority lookups. Priority lookup tables map impact and urgency values to incident priority, which is useful for incident SLA routing but has no bearing on how relationship records are walked during conflict detection.

sc_cart

Why it fails: sc_cart is a transient staging table for items before submission; once a request is placed, cart records are converted and no longer represent the submitted items, so the query returns nothing. It is tempting because the cart does hold items during ordering, but that is pre-submission, not workflow execution.

sys_user_has_role

Why it fails: sys_user_has_role stores user-to-role assignments for access control, containing no service catalog request or item data, so the query cannot return submitted items. It is tempting because workflows often check approvals and roles, but that table serves authorisation lookups, not catalog item retrieval.

sc_request

Why it fails: sc_request stores the request header, not the individual submitted items the workflow must act on; querying it returns no line items, so the Run Script activity still fails. It is tempting because a request record does exist for each submission, but sc_req_item is the table holding the requested items themselves.

Whether the user submitting the change has the security_admin role

Why it fails: Conflict detection evaluates schedule overlap and CI relationships regardless of the submitter's roles; security_admin governs access to restricted tables and UI actions, not change conflict logic. Investigators should instead check change windows, CI relationships, and whether conflict checking is enabled.

Whether the target CI classes are excluded from incident management

Why it fails: Conflict detection compares change schedules against CI relationships and maintenance windows, not incident management exclusions. CI class exclusions can suppress conflict checks, but the incident module plays no part, making this a plausible-sounding but irrelevant area to investigate.

Incident State

Why it fails: Incident state governs whether the SLA condition matches, but it is one condition among several and not the first checkpoint; the SLA definition's start, stop and pause conditions must be validated first. State matters when a correctly defined SLA fails to trigger at a specific transition.

System Dictionary

Why it fails: The System Dictionary stores field labels, choices and dependent relationships, not SLA definitions or start conditions, so it cannot explain why an SLA fails to attach. It is tempting because dictionary entries do underpin form behaviour, and editing them is the right fix when a field's choice list or dependency misbehaves.

User Preferences

Why it fails: User preferences affect notification and display settings, not SLA attachment logic, so they cannot prevent a matching SLA from attaching. Preferences would be relevant when a user reports missing alerts or a personalised view rather than a missing SLA record.

Check the 'No cart' attribute on the order guide record itself.

Why it fails: The 'No cart' attribute controls whether an order guide bypasses the cart and submits directly; it does not prevent Rule Base child items from being inserted. It would be the right setting to inspect when an order guide should skip cart review entirely.

Rewrite the rule base conditions using legacy javascript eval() statements.

Why it fails: Legacy eval() statements are not required for Rule Base conditions, which already evaluate server-side; rewriting them introduces deprecated scripting without addressing why the child item is skipped. Legacy eval() would matter only when migrating very old custom condition scripts that still depend on it.

Disable cascading variables on all child catalog items.

Why it fails: Cascading variables control how variable values propagate between catalog items; they do not govern whether a Rule Base adds a child item to the cart, so disabling them changes nothing here. Cascading variables would be relevant when child item variables must inherit or filter values from parent items.

Clear the browser cache and restart the instance JVM

Why it fails: Catalog UI Policy actions depend on the variable's value and the policy's conditions, not on cached browser state or the instance JVM, so clearing cache and restarting changes nothing. It is tempting as a generic ServiceNow remedy, and would be correct for stale client-side rendering issues rather than policy logic.

Convert the UI Policy into a Business Rule

Why it fails: Business Rules run server-side on record operations, not on client-side form variable changes, so the dependent-variable behaviour would not fire. Converting is tempting when logic must execute on the server, such as during record insert or update.

Change the UI Policy execution order to zero

Why it fails: Execution order zero does not resolve a non-firing action; order only sequences multiple policies, and zero is not a valid priority. Adjusting order is tempting when several UI Policies conflict, but the real cause is usually the action's variable or condition.

Child Incidents

Why it fails: Child Incidents lists incidents correlated to the problem, not the discrete investigation tasks assigned to resolver groups. It is tempting because child incidents are the related records most commonly associated with problems, and they are the correct place to review when you need the incident volume and affected users driving the problem.

Outages

Why it fails: Outages lists service outages linked to the problem, not the individual investigation tasks assigned to groups. It is tempting because outages are part of problem analysis, and the related list is genuinely used when assessing impact on services, but it never holds task records with assignment and state.

Affected CIs

Why it fails: Affected CIs lists configuration items impacted by the problem, not the assigned investigation tasks. It is tempting because affected CIs are central to problem analysis, and the related list is genuinely used when scoping which infrastructure the root cause touches, but it stores CI records rather than task assignments.

admin

Why it fails: The admin role grants broad platform administration but does not by itself surface the CAB Workbench module, which depends on the specific CAB roles. It is tempting because admin sounds all-encompassing, yet administrative privilege and CAB interface access are governed by separate role assignments.

itil

Why it fails: The itil role provides baseline ITIL process access for technicians, not the dedicated CAB Workbench interface. It is tempting because itil is the standard role assigned to service management staff, but CAB Workbench visibility requires the specific CAB-related roles rather than generic ITIL process permissions.

cab_analyst

Why it fails: cab_analyst supports analysis tasks rather than the CAB Workbench interface itself, so assigning it does not expose the module. It is tempting because the name references CAB, but the required access comes from the CAB manager or CAB member roles, not the analyst role.

change_manager

Why it fails: The change_manager role governs change approval and CAB membership, not access to the CAB Workbench interface itself, which is granted through the itil or sn_change_management roles. It is tempting because change managers run CAB meetings, but the interface requires the specific CAB Workbench role assignment.

The user has admin rights to the database

Why it fails: Catalog client scripts execute based on form interaction regardless of admin status, provided the item is accessible.

The script is written in Java rather than JavaScript

Why it fails: ServiceNow client scripts are strictly written in JavaScript.

Rebuild the Catalog Item cache

Why it fails: Rebuilding the cache only refreshes stale rendered content; it cannot reveal a variable hidden by an unmet condition or order rule, so it wastes the first diagnostic step. Cache rebuilds are for stale UI after confirmed configuration changes, not for a variable that never appeared.

Verify the Catalog Item workflow

Why it fails: Workflows execute approvals and tasks after submission; they do not control whether a variable renders on the form. Checking the workflow is relevant when a submitted request stalls, not when a variable fails to display.

Check the Variable Set order

Why it fails: Variable Set order governs display sequence, not visibility; a variable absent because its condition is unmet or it sits on an unrendered page stays hidden regardless of order. Order matters when variables appear but are sequenced incorrectly.

Problem state

Why it fails: The Problem state field indicates the lifecycle stage (e.g., New, Assess, Root Cause Analysis). It does not identify the team responsible. Filtering by state would show all problems in that state across all teams, not specifically those being investigated by the network team. It is useful for process tracking but not for team-based filtering.

Configuration item

Why it fails: The Configuration item field links the problem to a specific CI, such as a server or router. While network problems might be associated with network CIs, this field does not indicate which team is investigating. Filtering by CI would show problems related to that CI regardless of the assigned team, which does not meet the requirement.

Assigned to

Why it fails: The 'Assigned to' field refers to the individual user assigned to the problem, not the team. While a member of the network team might be assigned, filtering by this field would not reliably show all problems being investigated by the network team, as multiple individuals could be involved. It is used for personal task lists, not team-level filtering.