Hard Difficulty Questions

Schedules are automatically generated by ITOM Discovery based on server reboots

Why it fails: cmn_schedule records are created manually by administrators or change managers; ITOM Discovery populates the CMDB with configuration items and relationships, not schedules. It is tempting because Discovery does gather server data, but it never generates maintenance or blackout schedules from reboots.

Schedules are strictly limited to single-day events and cannot span multiple days

Why it fails: cmn_schedule records support recurring patterns and can span multiple days, for example a weekend change window starting Friday and ending Monday. Single-day-only is tempting because many maintenance windows are short, but the schema imposes no such limit.

In a Client Script running on the Email form

Why it fails: Client Scripts execute in the user's browser, so they cannot run during server-side inbound email processing, leaving the sender unchecked. It is tempting because Client Scripts are the correct choice for validating or altering form data when a user submits through the interface.

In the Dictionary entry for email body

Why it fails: Dictionary entries define field attributes such as type, length and default values; they cannot query the vendor company record or compare sender addresses. It is tempting because dictionary-level validation is the correct choice for enforcing data-format rules on a field regardless of entry channel.

In a UI Policy Action

Why it fails: UI Policy Actions run in the browser against form fields, so they never execute for inbound email processing, leaving the sender unvalidated. It is tempting because UI Policies are the correct choice for enforcing field behaviour when users interact with forms directly.

A Client Script validation check

Why it fails: A Client Script runs in the browser and validates form input; it cannot orchestrate server-side multi-stage approval routing or reliably enforce the financial threshold. It is tempting because it can react to field changes, and would be correct for form validation, but approval sequencing requires a Workflow or Flow.

An Email Notification template

Why it fails: Email Notification templates generate outbound messages; they cannot evaluate the $10,000 threshold or sequence approval stages. They are tempting because approvals are communicated by email, and would be correct for alerting approvers, but the routing logic itself must live in a Workflow or Flow.

A Dictionary Override on the Approval field

Why it fails: A Dictionary Override changes a field's label, default, or mandatory behaviour on a form; it cannot evaluate financial impact or route multi-stage approvals. It is tempting because it customises the Approval field, and would be correct for altering field attributes, but conditional orchestration needs a Workflow or Flow.

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.

It flags the payload in the IRE Error Dashboard as an identification conflict requiring manual resolution.

Why it fails: Attribute updates to non-key fields do not trigger an identification conflict error unless strict uniqueness fails.

It creates a new CI record because the IP address attribute does not match the historical value.

Why it fails: Creating a new record would defeat the purpose of identification rules, which are designed to update existing matching instances.

It deletes the existing CI and inserts a new one with the updated attributes.

Why it fails: Deleting and re-inserting breaks related incident and change history linked to the CI sys_id.

The IRE averages the weights and creates a new CI if the combined score is below 75.

Why it fails: Weights determine rule precedence when multiple rules exist, not algorithmic scoring of entries within a single rule.

The IRE rejects the payload because conflicting matching criteria are defined within the same rule.

Why it fails: Multiple entries in an identification rule are fully supported to handle different hardware matching scenarios.

UI Action on change_request

Why it fails: A UI Action executes only when a user clicks a button or link, so it cannot fire automatically on a record entering the New state. It is tempting because UI Actions commonly drive state transitions on forms, but unattended automation belongs in server-side logic that runs without user interaction.

State transition table

Why it fails: A state transition table defines which states a change can move between, not the automated trigger that fires the transition. It is tempting because transitions are its subject, but it only authorises the New-to-Assess path; the automation logic itself belongs in the workflow that runs on entering that state.

Business Rule on change_request

Why it fails: A Business Rule runs on database operations such as insert or update, not on state-model transitions, so it cannot reliably drive the New-to-Assess movement defined in the Change Model. It is tempting because Business Rules automate record changes generally, but Change Model transition logic is configured in the model itself.

Workflow properties

Why it fails: Workflow properties govern the overall Change Model's execution behaviour, not the per-state transition logic from New to Assess. It is tempting because workflows do drive automation, but that automation is triggered by the model's activity flow rather than by a state change, so the New-to-Assess move is never initiated here.

Catalog Client Script

Why it fails: This is for the Service Portal, not the agent view.

UI Policy

Why it fails: UI Policies only affect the form, not the database integrity.

Workflow

Why it fails: Workflows don't typically enforce field requirements in this way.

Dot-walk directly to current.variables.mrvs_name.column_name in the task activity.

Why it fails: MRVS values are stored as a JSON string, so dot-walking to current.variables.mrvs_name.column_name returns nothing — the column is not a real field. It tempts because dot-walking works for standard single-row variables, and would be correct if the variable set held only one row rather than an array.

Use a Record Producer script to flatten the MRVS into custom table rows automatically.

Why it fails: Record Producer scripts run at catalog submission to create the target record; they do not flatten MRVS JSON into custom table rows automatically, and the scenario needs extraction inside a workflow script. It tempts because Record Producers do map variables to record fields, which is correct when no workflow-stage processing is required.

Configure a Catalog UI Policy to export MRVS rows to the sys_variable_value table.

Why it fails: Catalog UI Policies control form field visibility and behaviour on the catalog form; they cannot export MRVS rows to sys_variable_value, which is populated automatically when the submitted record is created. It tempts because UI Policies do manipulate catalog variables, but only client-side display logic, not server-side JSON parsing for task population.

Write a Client Script on the sc_cart table to intercept the checkout action.

Why it fails: An sc_cart Client Script fires at checkout, after the item has already been added to the cart, so it cannot block submission of the catalogue form. It is tempting because cart scripts do govern checkout validation, but the requirement is to validate the ten checkboxes at the point of submission, which needs an onSubmit script on the catalogue item's own table.

Configure a Dictionary Override on the sc_req_item table to enforce mandatory checkboxes.

Why it fails: Dictionary Overrides enforce mandatory fields at the database layer on sc_req_item, which runs after submission and cannot inspect ten client-side checkbox values before the cart action. It is tempting because overrides are the standard way to make fields mandatory, and would be correct for server-side enforcement on a single field.

Use document.getElementsByClassName() to count checked elements directly from the DOM.

Why it fails: ServiceNow client scripts should use the g_form API; reading the DOM directly bypasses the platform's field model and breaks with UI changes. It is tempting because DOM counting is familiar from general web development, and would be correct for a standalone HTML page outside the ServiceNow form framework.

Use synchronous GlideRecord queries inside client-side OnChange scripts for instant validation.

Why it fails: Synchronous queries are deprecated and blocked in Service Portal.

Write all client scripts using jQuery selector syntax for broad browser support.

Why it fails: jQuery is discouraged and not natively standard for Service Portal catalog client scripts.

Write a Data Policy targeting the Requested Item table.

Why it fails: Incorrect. Data policies enforce rules at the database level, but catalog item variables reside in staging tables prior to submission and are best validated client-side.

Configure a Catalog UI Policy Action with a script condition checking character count.

Why it fails: Incorrect. UI policy actions control field attributes (mandatory, read-only, visible), whereas length validation is handled via client scripts.

Define a variable attribute with the parameter 'min_length=50'.

Why it fails: Incorrect. Variable attributes do not natively support a generic min_length validation parameter out of the box without custom client script support.

The social media platform handle for public announcements

Why it fails: Social media handles are unrelated to database archiving rules.

The airline frequent flyer account for the archivist

Why it fails: Frequent flyer accounts are personal travel details, not system configurations.

Automatic execution of incident management triage workflows for failed discoveries.

Why it fails: CI Class Manager governs class definitions, hierarchies and attributes; it does not execute incident triage workflows, which belong to Flow Designer or Incident Management. It is tempting because failed discoveries do generate alerts, but remediation is handled elsewhere, not by class configuration.

Direct editing of system-level Java source code for Discovery patterns.

Why it fails: CI Class Manager is a configuration interface for class hierarchies and attributes, not a code editor; pattern logic is changed in Discovery pattern scripts. It is tempting because class changes affect pattern output, but direct Java editing happens in the pattern designer, not here.

Workflow Designer transition lines only

Why it fails: Transition lines only draw the workflow path; without the states registered in the Change State Model configuration, the framework cannot validate or process them. It is tempting because transitions visually represent state movement, but the model requires the state definitions themselves, not just the arrows between them.

System Dictionary choices on the state field only

Why it fails: Dictionary choices alone render the states in the UI but do not register them with the Change State Model, so transitions and model validation fail. It is tempting because dictionary entries are required for any custom state, yet the model framework also needs the states defined in its own configuration.

UI Actions script bodies

Why it fails: UI Action scripts control button behaviour and visibility, not state registration; the Change State Model would still reject undefined states. It is tempting because UI Actions often accompany state changes, but they execute client-side logic rather than defining the states the framework recognises.

An Access Control List (ACL) with script execution

Why it fails: ACLs control read/write/create/delete access to records and fields, not workflow state transition validation.

A Dictionary Override on the State field

Why it fails: Dictionary overrides only control default values, mandatory status, or read-only status per table/class, not multi-table relational validation.

A UI Policy with an advanced script condition

Why it fails: UI policies run on the form client-side and can be easily bypassed if updates occur via web services or server scripts.

Ensure the API user has the 'itil' role.

Why it fails: The itil role grants access to the incident table but does not itself cause assignment rules to evaluate; those rules run on insert through the assignment engine, which API writes can bypass. It is tempting because role-based access is genuinely required when the API user lacks permission to read or write incident records.

Set the 'auto_assignment' flag to true.

Why it fails: No 'auto_assignment' flag exists on the incident record or REST payload; assignment rules fire through the Assignment Rules engine triggered by the sysparm_input_display_value parameter or a business rule. It tempts because other platforms use boolean flags to enable auto-assignment, but ServiceNow does not.

Enable the 'Run Assignment Rules' checkbox in the API call.

Why it fails: ServiceNow's REST API ignores a 'Run Assignment Rules' checkbox; assignment rules execute only when the Table API is called with sysparm_input_display_value or via a business rule, so the field simply doesn't exist. It tempts because UI forms expose similar toggles, but those are client-side, not API parameters.

Scheduled jobs running nightly

Why it fails: Scheduled jobs run at fixed intervals, so they cannot fire at the moment a Normal Change enters 'Assess', and they do not send the questionnaire to the assignee. They are tempting because they suit recurring batch work, and would be correct for periodic housekeeping such as ageing reports or SLA sweeps.

Email notifications with mail scripts

Why it fails: Mail scripts only compose and send email; they do not generate or assign the risk assessment questionnaire itself, so the assessment is never created for the assignee. They are tempting because notifications accompany the process, and would be correct for alerting users about an event rather than instantiating an assessment.

Client scripts on the change request form

Why it fails: Client scripts execute in the browser on form events, so they cannot reliably trigger server-side questionnaire delivery when the state changes through background or API updates. They are tempting because they handle interactive form behaviour, and would be correct for validating fields or showing messages as the user edits the record.

Update the Dictionary entry.

Why it fails: The Dictionary entry controls field properties such as default value, mandatory state and read-only behaviour globally, but it cannot conditionally hide a field only for non-admin users. It is tempting because dictionary changes apply platform-wide, which would be correct for enforcing a permanent, role-independent field attribute.

Use a Data Policy.

Why it fails: Data Policies restrict field access at the table and field level through role-based rules, but they are designed for data classification and segregation, not for hiding a field purely by role on a form; ACL or dictionary-level control is required. It is tempting because data policies genuinely govern which roles may read or write fields.

Use a UI Policy.

Why it fails: A UI Policy only manipulates form field visibility, mandatory and read-only states on the client; it does not secure the underlying data, so non-admin users could still read Impact via lists, reports or APIs. It is tempting because UI Policies are the standard mechanism for hiding fields on forms, which would be right for cosmetic form behaviour.

CAB Meeting [cab_meeting]

Why it fails: Unrelated.

Change Request [change_request]

Why it fails: This is the parent table.

Task Rel [task_rel]

Why it fails: Not the correct table for this relationship.

Task [task]

Why it fails: Too generic.