Troubleshooting practice questions

An administrator is troubleshooting why conflict detection is not running when changes are updated via a REST API integration. Which condition in the conflict detection business rule might prevent execution during API calls?

Trap 1: Conflict detection requires an interactive web browser session

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.

Trap 2: REST APIs inherently disable all database business rules globally

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.

Trap 3: Integration accounts lack read access to the cmdb_ci table

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.

A
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.
B
The business rule checks if the update modifies schedule-related fields (like planned start/end or CI) and runs accordingly
Conflict detection only fires when the update touches the schedule-related fields the rule inspects, so REST API changes altering other fields bypass it. This condition directly explains why detection does not run during those API calls.
C
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.
D
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.

Question 2hardmultiple choice

You are investigating why an incident was not auto-assigned. You check the Assignment Rules but notice the 'Match Conditions' are met. What is another common reason?

Trap 1: The 'Assigned to' field is already populated.

A populated 'Assigned to' field blocks the assignment rule from firing, since the rule only sets assignment when that field is empty. It tempts because manual assignment is a genuine cause of skipped auto-assignment, and would be correct where an analyst had already claimed the incident before the rule evaluated.

Trap 2: The incident is in a closed state.

A closed incident still has its assignment rule evaluated at creation; the state alone does not suppress auto-assignment. It tempts because closed records are excluded from many active workflows, and would be correct where a rule condition explicitly filters out incidents in closed states.

Trap 3: The incident was created via an Email Inbound Action.

Email inbound actions can create incidents that bypass assignment rules only when configured to do so; creation via email alone does not prevent rule evaluation. It tempts because inbound actions are a real auto-assignment mechanism, and would be correct where the action explicitly sets assignment instead of the rule.

A
The Assignment Rule is not active.
Assignment rules only execute when active; an inactive rule is skipped entirely regardless of whether its match conditions are satisfied. Since the stem confirms conditions are met, the rule's inactive state is the remaining common cause preventing auto-assignment.
B
The 'Assigned to' field is already populated.
Why it fails: A populated 'Assigned to' field blocks the assignment rule from firing, since the rule only sets assignment when that field is empty. It tempts because manual assignment is a genuine cause of skipped auto-assignment, and would be correct where an analyst had already claimed the incident before the rule evaluated.
C
The incident is in a closed state.
Why it fails: A closed incident still has its assignment rule evaluated at creation; the state alone does not suppress auto-assignment. It tempts because closed records are excluded from many active workflows, and would be correct where a rule condition explicitly filters out incidents in closed states.
D
The incident was created via an Email Inbound Action.
Why it fails: Email inbound actions can create incidents that bypass assignment rules only when configured to do so; creation via email alone does not prevent rule evaluation. It tempts because inbound actions are a real auto-assignment mechanism, and would be correct where the action explicitly sets assignment instead of the rule.

Question 3hardmulti select

An administrator is troubleshooting why conflict detection is not evaluating custom CI relationship types. Which THREE components control how CI relationships are traversed during conflict detection? (Choose three.)

Trap 1: Service Catalog workflow versioning rules

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.

Trap 2: Incident management priority lookup tables

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.

A
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.
B
CI relationship type definitions (cmdb_rel_type) specifying upstream/downstream semantics
CI relationship type definitions in cmdb_rel_type carry the parent/child and upstream/downstream semantics that conflict detection traverses, so custom types must be defined there before evaluation occurs. Without these directional definitions, the engine cannot resolve how custom relationships connect CIs, leaving them unevaluated during conflict detection.
C
Conflict detection system properties enabling relationship traversal
Conflict detection system properties govern whether relationship traversal occurs at all and which relationship types are considered. If traversal is disabled or a custom type is excluded by property configuration, conflict detection skips those CIs entirely, explaining the missing evaluation.
D
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.
E
Script includes (such as ConflictFinderSNC) containing the traversal query logic
The ConflictFinderSNC script include holds the query logic that walks CI relationships during conflict detection. Custom relationship types must be handled by this traversal logic; otherwise the script never follows those links, so conflicts involving them go undetected.

Question 4hardmultiple choice

You are troubleshooting a scenario where an Incident SLA is not attaching to a ticket. What is the first place you should investigate?

Trap 1: Incident State

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.

Trap 2: System Dictionary

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.

Trap 3: User Preferences

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.

A
SLA Definition Conditions
SLA definitions carry start, stop, pause and reset conditions that determine whether a record qualifies for attachment. If these conditions reference fields the ticket does not populate, or exclude its values, no SLA binds. Verifying them first satisfies the stem's requirement to find why attachment fails before checking workflows or schedules.
B
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.
C
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.
D
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.

Question 5hardmultiple choice

An administrator is troubleshooting an Order Guide where Rule Base conditions evaluate to true, but the expected child catalog item is not being added to the cart. What is a valid troubleshooting step in this scenario?

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

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.

Trap 2: Rewrite the rule base conditions using legacy javascript eval()…

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.

Trap 3: Disable cascading variables on all child catalog items.

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.

A
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.
B
Verify that the child catalog item is active and that the submitting user satisfies the child item's User Criteria.
Rule Base conditions can evaluate true while the child item is still excluded, because inactive items or unmet User Criteria prevent addition. Confirming the child catalog item's active status and the submitting user's User Criteria eligibility isolates that cause.
C
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.
D
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.

Question 6hardmultiple choice

An administrator has configured a Catalog UI Policy with a Catalog UI Policy Action. However, the action is not taking effect when the dependent variable changes value. What is a common troubleshooting step for Catalog UI Policies?

Trap 1: Clear the browser cache and restart the instance JVM

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.

Trap 2: Convert the UI Policy into a Business Rule

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.

Trap 3: Change the UI Policy execution order to zero

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.

A
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.
B
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.
C
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.
D
Verify that 'Applies on Target' (such as Service Portal or Catalog Item) is correctly checked on the UI Policy definition
Catalog UI Policies only run against the interface or target specified in 'Applies on Target'. If that checkbox omits the relevant Service Portal or Catalog Item, the policy and its actions never execute when the dependent variable changes, so verifying it is the first troubleshooting step.

Question 7hardmulti select

An administrator is troubleshooting a Catalog Client Script that is not executing properly on a Service Portal catalog item. Which THREE factors should be verified? (Choose three.)

Trap 1: The user has admin rights to the database

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

Trap 2: The script is written in Java rather than JavaScript

ServiceNow client scripts are strictly written in JavaScript.

A
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.
B
The 'UI Type' field is set to 'Mobile/Service Portal' or 'All'
Scripts configured exclusively for Desktop (UI Type = Desktop) will not execute in Service Portal.
C
The correct variable name is referenced in the script and applies to the catalog item
Client scripts must target valid variable names and be correctly associated with the catalog item or variable set.
D
The script is written in Java rather than JavaScript
Why it fails: ServiceNow client scripts are strictly written in JavaScript.
E
The script is marked as 'Active'
Inactive scripts do not execute.

Question 8hardmultiple choice

A user reports that a variable is not appearing on a Catalog Item form, even though the variable is active and associated with the item. Which troubleshooting step should be performed first?

Trap 1: Rebuild the Catalog Item cache

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.

Trap 2: Verify the Catalog Item workflow

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.

Trap 3: Check the Variable Set order

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.

A
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.
B
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.
C
Inspect Catalog UI Policies and Catalog Client Scripts for visibility logic
Catalog UI Policies and Catalog Client Scripts commonly hide or show variables dynamically, so a variable that is active and correctly associated can still be invisible at runtime. Inspecting their visibility conditions first identifies whether client-side logic is suppressing the field.
D
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.