Courseiva

CCNA Service Catalog And Request Management Questions

26 of 101 questions · Page 2/2 · Service Catalog And Request Management topic · Answers revealed

Practice these questionsExam hubAll questions
76
MCQeasy

Which table stores the individual requested items (RITMs) created when a user checks out a cart from the Service Catalog?

A.sc_cat_item
B.sc_request
C.incident
D.sc_req_item
AnswerD

The sc_req_item table holds each individual requested item generated when a catalog cart is submitted, one record per line item. The parent request record lives in sc_request, so sc_req_item satisfies the requirement for storing the individual RITMs.

Why this answer

The sc_req_item table stores individual Requested Items (RITMs) — one record per catalog item checked out in a cart. When a user submits a cart, ServiceNow creates one sc_request record and one sc_req_item record per distinct catalog item, making sc_req_item the correct answer.

Exam trap

CIS-ITSM often tests the confusion between sc_request (the parent REQ) and sc_req_item (the RITM line item), causing candidates to pick sc_request when asked about individual requested items.

How to eliminate wrong answers

Option A is wrong because sc_cat_item is the catalog item definition table (the template), not the transactional record. Option B is wrong because sc_request stores the parent request header, not the individual line items. Option C is wrong because incident is the ITSM incident table, unrelated to catalog checkout.

Practice this question →
77
MCQmedium

A ServiceNow implementation specialist is designing a Catalog Item where the visibility of a custom variable named 'server_os' must dynamically change depending on the selection of another variable named 'request_type'. Which configuration tool is best suited for this requirement?

A.Data Policy
B.Business Rule
C.Catalog Client Script
D.Catalog UI Policy
AnswerD

Catalog UI Policies run client-side logic that shows, hides, or makes mandatory variables based on another variable's value, which is exactly the dynamic dependency between request_type and server_os. They act on the catalogue form without altering stored data.

Why this answer

Catalog UI Policies are specifically designed to dynamically control the visibility, mandatory, and read-only state of catalog item variables based on the values of other variables on the form, all without requiring a server round-trip. They execute client-side and are the native, declarative tool for this exact requirement. Since the requirement is to change visibility of 'server_os' based on 'request_type', a Catalog UI Policy is the correct and most efficient choice.

Exam trap

CIS-ITSM often tests the confusion between client scripts and UI policies, where candidates might choose a client script for dynamic visibility because they think scripting is always needed, but the exam expects knowledge of declarative UI Policies as the best-suited tool for simple show/hide requirements.

How to eliminate wrong answers

Option A is wrong because Data Policies are server-side rules that enforce mandatory, read-only, and default values on task records (like incident or change), not on catalog item variables, and they cannot dynamically show/hide variables on a catalog form. Option B is wrong because Business Rules run on the server and are used for database operations, record manipulation, and server-side logic; they cannot directly control client-side variable visibility in real time without additional scripting and are not the intended tool for this UI behavior. Option C is wrong because Catalog Client Scripts are used for custom client-side scripting (e.g., onChange, onLoad, onSubmit) and while they can achieve visibility changes, they require custom code and are not the best-suited declarative tool for simple visibility toggles; UI Policies are preferred for such requirements.

Practice this question →
78
MCQhard

An administrator created a Multi-Row Variable Set (MRVS) and wants to populate a field on the target task using the data collected in the MRVS rows. Since MRVS stores data as a JSON string, what is the best way to extract and process this data in a workflow script?

A.Dot-walk directly to current.variables.mrvs_name.column_name in the task activity.
B.Use a Record Producer script to flatten the MRVS into custom table rows automatically.
C.Configure a Catalog UI Policy to export MRVS rows to the sys_variable_value table.
D.Parse the JSON string using JSON.parse(current.variables.mrvs_name) in a Run Script activity and iterate through the resulting array.
AnswerD

MRVS values are stored as a JSON string, so JSON.parse converts it into an array of row objects. A Run Script activity can then iterate that array to read each row's fields and write the required value onto the target task record.

Why this answer

The MRVS stores its collected row data as a JSON string in the variable value, so the only reliable way to access individual columns is to parse that string into a JavaScript object/array. JSON.parse(current.variables.mrvs_name) converts the serialized rows into an array of objects, which a Run Script workflow activity can then iterate over to read each row's column values and write them to the target task fields. Direct dot-walking (Option A) does not work because the MRVS is not a true related list of child records — it is a single variable holding a JSON payload, so there are no column-level fields to traverse.

Exam trap

CIS-ITSM often tests the misconception that MRVS variables behave like related lists or child records that can be dot-walked directly, when in fact they are JSON strings requiring explicit parsing.

How to eliminate wrong answers

Option A is wrong because dot-walking assumes the MRVS is backed by child records with addressable column fields, but it is actually a single variable containing a JSON string, so current.variables.mrvs_name.column_name resolves to nothing. Option B is wrong because a Record Producer script is used to create records from a catalog item submission, not to flatten an existing MRVS into custom table rows during a workflow; it also does not address the JSON parsing requirement. Option C is wrong because a Catalog UI Policy controls form field behavior on the catalog form (visibility, mandatory, read-only) and cannot export MRVS rows to sys_variable_value; the MRVS data is already stored as a variable value, not as separate rows to export.

Practice this question →
79
MCQeasy

What is the primary benefit of using Variable Sets in the ServiceNow Service Catalog?

A.To create reusable collections of variables that can be shared across multiple catalog items
B.To enforce database-level table normalization
C.To automatically close requests upon creation
D.To replace the need for workflows entirely
AnswerA

Variable Sets let you define one collection of variable definitions and attach it to many catalog items, so updates propagate everywhere. This directly satisfies the stem's reusability constraint, eliminating duplicated maintenance across items and keeping question sets consistent without rebuilding them per item.

Why this answer

Variable Sets are reusable containers of variable definitions (questions) that can be attached to multiple catalog items, eliminating the need to recreate identical questions on each item. When a variable set is updated, the change propagates to every catalog item that references it, ensuring consistency across the catalog. This is the core design intent: define once, reuse everywhere.

Exam trap

CIS-ITSM often tests whether candidates confuse Variable Sets (reusable variable containers) with UI Policies, Data Policies, or workflows — the trap is picking an answer that describes a control mechanism rather than a reuse mechanism.

How to eliminate wrong answers

Option B is wrong because Variable Sets have nothing to do with database table normalization — normalization is a schema design concern handled via table relationships and dictionary configuration, not catalog variables. Option C is wrong because automatically closing requests upon creation is a workflow/flow or business rule behavior, not a function of Variable Sets. Option D is wrong because Variable Sets only supply variable definitions; workflows, flows, and approval engines are still required to drive fulfillment and task orchestration.

Practice this question →
80
MCQmedium

An administrator needs to ensure that a set of variables appears on multiple Catalog Items without having to recreate them individually for each item. Which feature should the administrator configure?

A.Catalog Client Script Template
B.Record Producer
C.Variable Set
D.Order Guide
AnswerC

A Variable Set is a reusable collection of variables that can be attached to many Catalog Items, so the administrator defines the variables once and references the set rather than recreating them per item. This satisfies the requirement to surface identical variables across multiple items.

Why this answer

A Variable Set is a reusable container of variables that can be attached to multiple Catalog Items, so the administrator defines the variables once and references the set on each item. This avoids duplicating variable definitions across items and keeps them synchronized when changes are needed.

Exam trap

CIS-ITSM often tests whether candidates confuse Variable Sets (reusable variable containers) with Order Guides (bundled item ordering) or Record Producers (direct record creation) — the key differentiator is 'reuse variables across items.'

How to eliminate wrong answers

Option A is wrong because a Catalog Client Script Template is not a ServiceNow feature for sharing variables — client scripts are attached individually to items or via UI policies, not templated for variable reuse. Option B is wrong because a Record Producer creates records on a target table; it does not share variables across catalog items. Option D is wrong because an Order Guide groups multiple catalog items into a single ordering flow, not a mechanism for reusing variable definitions.

Practice this question →
81
MCQhard

An organization requires that when a user submits an order guide, the fulfillment workflow needs to evaluate rules to determine which catalog items are included based on user input. Where are these rules defined?

A.Order Guide Item Mappings
B.Rule Base
C.Catalog Client Scripts
D.Workflow Canvas
AnswerB

The Rule Base holds the decision logic that the fulfilment workflow evaluates against user input to determine which catalog items an order guide includes. Rules are authored there, so it is where inclusion criteria are defined and executed during submission.

Why this answer

The Rule Base is the component within an Order Guide that defines the conditional logic (rules) used to evaluate user input and determine which catalog items are dynamically included in the order. It contains the conditions and associated catalog items that get added when those conditions are met. This is the core mechanism for dynamic item selection in Order Guides.

Exam trap

CIS-ITSM often tests the confusion between the Rule Base (which controls item inclusion) and Item Mappings (which control variable cascading), so candidates must distinguish between these two Order Guide components.

How to eliminate wrong answers

Option A is wrong because Order Guide Item Mappings are used to map variables between the order guide and child items, not to define inclusion rules. Option C is wrong because Catalog Client Scripts run client-side JavaScript for form behavior (e.g., showing/hiding fields) and do not control which items are included in an order guide. Option D is wrong because Workflow Canvas is the graphical workflow editor for process automation, not for defining order guide inclusion rules.

Practice this question →
82
MCQhard

A fulfillment team requires a workflow to dynamically branch based on the value of a choice variable selected in a Catalog Item. Which activity should be placed in the Flow Designer flow to evaluate this condition?

A.If
B.Wait for Condition
C.Switch Case
D.Ask for Approval
AnswerA

The If flow logic activity evaluates a condition and branches the flow down different paths based on the outcome. Referencing the catalog item's choice variable in its condition lets the workflow dynamically route according to the selected value.

Why this answer

The 'If' activity in Flow Designer is used to evaluate a condition and branch the flow based on the result. It directly supports dynamic branching based on any variable or data available in the flow, including a choice variable from a catalog item. This is the standard way to implement conditional logic in Flow Designer.

Exam trap

CIS-ITSM often tests the difference between 'If' and 'Switch Case' in Flow Designer, and candidates may overcomplicate by choosing 'Switch Case' when a simple condition is needed.

How to eliminate wrong answers

Option B is wrong because 'Wait for Condition' pauses the flow until a condition is met, but it does not branch; it simply waits, which is not suitable for immediate branching based on a variable value. Option C is wrong because 'Switch Case' is used for multi-branch logic based on a single value, but the question asks for evaluating a condition (likely a simple true/false or specific value) and the 'If' activity is the direct equivalent for conditional branching. Option D is wrong because 'Ask for Approval' is used to request approval, not to evaluate a variable and branch.

Practice this question →
83
MCQhard

When designing a Record Producer that maps user input to the Incident table, an administrator notices that the 'Caller' field on Incident is not populating correctly even though the variable is mapped to 'caller_id'. What is the most likely reason?

A.The variable name must exactly match 'sys_id' to populate reference fields.
B.The variable type is set to Single Line Text instead of Reference pointing to the sys_user table.
C.Record producers cannot map fields to the Incident table due to security restrictions.
D.The Incident table requires an active Business Rule to accept record producer inputs.
AnswerB

A Single Line Text variable stores a string, so the mapped caller_id value cannot resolve to a sys_user reference, leaving Caller empty. Setting the variable type to Reference against sys_user satisfies the stem's requirement for correct caller population.

Why this answer

For a Record Producer to correctly populate a reference field like Caller on the Incident table, the variable mapped to that field must be of type Reference and point to the sys_user table. A Single Line Text variable, even if named 'caller_id', will store a string value that cannot be resolved to a valid user sys_id, resulting in an empty or incorrect Caller field. The mapping process relies on the variable's type to determine how to transfer data to the target field.

Exam trap

CIS-ITSM often tests the misconception that variable names alone determine mapping success, when in fact the variable type must match the target field type, especially for reference fields.

How to eliminate wrong answers

Option A is wrong because the variable name does not need to match 'sys_id'; the mapping is defined by the variable's name matching the field name (e.g., 'caller_id') and the variable type must be Reference. Option C is wrong because Record Producers are fully capable of mapping to the Incident table; security restrictions are managed via ACLs, not an inherent limitation. Option D is wrong because no active Business Rule is required for Record Producer inputs; the mapping is handled by the platform's built-in record creation process.

Practice this question →
84
MCQmedium

When creating a Catalog Client Script, what is the purpose of selecting 'Mobile / Service Portal' as the UI type?

A.It ensures the script executes correctly in Service Portal and mobile interfaces where DOM manipulation is restricted.
B.It restricts the script to run exclusively on native iOS and Android mobile apps.
C.It bypasses client-side caching for catalog item variables.
D.It automatically converts jQuery syntax into AngularJS directives.
AnswerA

Service Portal and mobile render outside the classic Jelly DOM, so scripts relying on direct DOM manipulation fail. Selecting this UI type targets the script at those interfaces and enforces the restricted API model they require.

Why this answer

Selecting 'Mobile / Service Portal' as the UI type in a Catalog Client Script ensures the script is compatible with the Service Portal and mobile interfaces, which use AngularJS instead of the classic Jelly/Prototype-based UI. In these environments, direct DOM manipulation (e.g., using $j or document.getElementById) is restricted or behaves differently, so the script must use the client-side API (g_form, g_user, etc.) that abstracts the UI. This option correctly identifies that the script executes properly in those interfaces by adhering to their constraints.

Exam trap

CIS-ITSM often tests the misconception that 'Mobile / Service Portal' restricts scripts to native mobile apps or that it enables automatic jQuery-to-AngularJS conversion, when in fact it simply ensures compatibility with the AngularJS-based interfaces by enforcing the use of the client-side API.

How to eliminate wrong answers

Option B is wrong because 'Mobile / Service Portal' does not restrict the script to native mobile apps; it applies to any Service Portal or mobile interface, including web-based portals. Option C is wrong because UI type selection has no impact on client-side caching; caching is controlled by browser settings or cache-busting mechanisms, not by the script's UI type. Option D is wrong because the platform does not automatically convert jQuery to AngularJS; developers must write scripts using the provided client-side API, and jQuery is not supported in Service Portal.

Practice this question →
85
MCQeasy

A catalog administrator needs to create a collection of variables that can be reused across multiple catalog items. Which feature should they use?

A.Variable Templates
B.Variable Sets
C.Variable Collections
D.Catalog Item Groups
AnswerB

Variable Sets group reusable variables that can be attached to many catalog items, so the administrator defines values once and references them everywhere. This satisfies the requirement to share variables across multiple catalog items without duplication.

Why this answer

Variable Sets are reusable collections of variables that can be attached to multiple catalog items, allowing administrators to define a set of variables once and include it wherever needed. This promotes consistency and reduces duplication across catalog items.

Exam trap

CIS-ITSM often tests the confusion between Variable Sets and non-existent features like Variable Templates or Variable Collections, when Variable Sets are the correct reusable variable mechanism.

How to eliminate wrong answers

Option A is wrong because Variable Templates are not a standard ServiceNow feature for reusable variable collections; the correct feature is Variable Sets. Option C is wrong because Variable Collections is not a ServiceNow catalog feature; it is a distractor term. Option D is wrong because Catalog Item Groups are used to organize catalog items into categories or groups, not to reuse variables across items.

Practice this question →
86
MCQhard

During an order guide configuration, an administrator needs to ensure that specific catalog items are automatically added to the cart based on the user's answers in the initial 'Describe Needs' prompt. Where should the administrator define this logic?

A.Order Guide Rule Base
B.Workflow Properties
C.Cart Layout
D.Catalog Client Script
AnswerA

The Order Guide Rule Base is the only place where conditional logic can be defined to add catalog items automatically, based on responses to the 'Describe Needs' prompt. It evaluates user answers and triggers the appropriate inclusion of items, satisfying the requirement for dynamic cart population during order guide configuration.

Why this answer

Order Guide Rule Base is the configuration area where administrators define rules that determine which catalog items are included in the cart based on the user's answers to the initial 'Describe Needs' questions. Each rule specifies a condition (based on the order guide's variables) and the catalog items to add when the condition is true. This is the native mechanism for conditional item inclusion in an order guide.

Exam trap

CIS-ITSM often tests the confusion between order guide rule logic (Rule Base) and client-side form logic (Catalog Client Script), causing candidates to pick the client script option for server-side cart composition.

How to eliminate wrong answers

Option B is wrong because Workflow Properties control workflow behavior (e.g., stages, activities), not the conditional inclusion of catalog items in an order guide cart. Option C is wrong because Cart Layout defines the visual arrangement of the cart, not the logic for adding items. Option D is wrong because a Catalog Client Script runs on the catalog item form and cannot govern order guide rule evaluation, which is a server-side order guide feature.

Practice this question →
87
MCQmedium

An organization uses custom pricing for specific catalog items based on user attributes or quantities. Where is item pricing primarily configured for a standard catalog item?

A.Workflow transition conditions
B.Service Level Agreement (SLA) definition
C.Order Guide Rule Base
D.Catalog Item form (Price and Recurring Price fields)
AnswerD

Custom pricing for catalog items is stored directly on the Catalog Item record, where the Price and Recurring Price fields hold the values used when the item is ordered. Configuring these fields satisfies the requirement for attribute- or quantity-based custom pricing without relying on separate price lists.

Why this answer

For a standard catalog item, the Price and Recurring Price fields on the Catalog Item form are the primary place where item pricing is configured. These fields define the one-time and recurring costs that appear on the catalog item and flow into the resulting request and price records. Custom pricing based on user attributes or quantities is then layered on via pricing rules or scripts, but the base price lives on the Catalog Item form.

Exam trap

CIS-ITSM often tests whether candidates know that base pricing lives on the Catalog Item form, while dynamic pricing rules are separate — candidates mistakenly pick workflow or SLA options that sound related to 'configuration.'

How to eliminate wrong answers

Option A is wrong because workflow transition conditions control the flow of approvals and task execution, not pricing — they determine when a record moves between states. Option B is wrong because an SLA definition governs response and resolution time targets, not item cost. Option C is wrong because an Order Guide Rule Base controls which catalog items are included or excluded in an order guide based on user answers, not the price of an individual item.

Practice this question →
88
MCQhard

A catalog item 'Software Request' includes a variable 'Justification' that should only be visible when the 'Request Type' variable is set to 'New Software'. The 'Justification' variable is part of a Variable Set that is used in multiple catalog items. The administrator needs to ensure the visibility rule applies consistently across all items where the set is used, without modifying each item individually. What should the administrator do?

A.Create a Catalog Client Script on each catalog item that uses the Variable Set to hide the 'Justification' variable based on 'Request Type'.
B.Modify the Variable Set to include a condition that hides the 'Justification' variable unless 'Request Type' is 'New Software'.
C.Create a Catalog UI Policy on the Variable Set record that hides the 'Justification' variable when 'Request Type' is not 'New Software'.
D.Create a UI Policy on the 'Request Type' variable that sets the 'Justification' variable to not visible when the condition is met.
AnswerC

Catalog UI Policies can be defined on Variable Sets, and they apply to all catalog items that include that set. This ensures consistent behavior without editing each item. The policy can target the specific variable within the set and use a condition on the 'Request Type' variable. This is the most efficient and maintainable approach, as changes to the policy automatically propagate to all items using the set.

Why this answer

Catalog UI Policies can be defined on Variable Sets, and they apply wherever the set is used. This centralizes the visibility rule for the 'Justification' variable, ensuring it only appears when 'Request Type' is 'New Software' across all catalog items. This avoids per-item customization and maintains consistency.

Other options either require individual item changes, incorrectly assume UI Policies on variables propagate, or misunderstand Variable Set capabilities.

Exam trap

The trap here is thinking that UI Policies on individual variables automatically apply to all instances of a Variable Set, when in fact the policy must be defined on the Variable Set itself to propagate.

Practice this question →
89
MCQeasy

An administrator needs to create a variable that is shared across multiple catalog items in ServiceNow. Which feature should the administrator use to achieve this efficiently without recreating the variables each time?

A.Order Guide
B.Catalog UI Policy
C.Record Producer
D.Variable Set
AnswerD

A Variable Set groups variables into a reusable container that can be attached to many catalog items, so the administrator defines the variables once and references the set everywhere. This avoids recreating identical variables per item, meeting the efficiency requirement.

Why this answer

A Variable Set is a reusable container of variables that can be attached to multiple catalog items, record producers, or other variable sets. This allows the administrator to define variables once and share them across items without recreating them, which is exactly the requirement.

Exam trap

CIS-ITSM often tests the misconception that Order Guides or UI Policies can share variables across items, when the correct feature for reusable variable definitions is the Variable Set.

How to eliminate wrong answers

Option A is wrong because an Order Guide groups multiple catalog items into a single ordering flow — it does not share variables across items. Option B is wrong because a Catalog UI Policy controls variable behavior (visibility, mandatory, read-only) on a single item; it does not share variable definitions. Option C is wrong because a Record Producer creates records from a catalog-like form but does not provide a mechanism for sharing variables across multiple catalog items.

Practice this question →
90
MCQmedium

When configuring User Criteria to restrict a catalog item so that only members of the 'HR' department can view it, where should this user criteria be attached?

A.In the 'User Criteria' related list on the Catalog Category form.
B.In the 'Available For' related list on the Catalog Item form.
C.In the 'Audience' field of the Service Portal Page record.
D.In the 'Access Control' rules mapped to the sc_cat_item table.
AnswerB

User Criteria restricting visibility must be attached via the 'Available For' related list on the Catalog Item form, which controls which users or groups can see and request the item. This satisfies the requirement that only HR department members can view it.

Why this answer

User Criteria that restrict a catalog item to a specific department are attached in the 'Available For' related list on the Catalog Item form. This related list is the supported mechanism for granting visibility to specific users, groups, or departments, and it is evaluated by the catalog visibility engine when users browse or search the catalog.

Exam trap

CIS-ITSM often tests the difference between User Criteria on the Catalog Item form versus ACLs on sc_cat_item — the trap is picking the ACL option because it sounds more secure, but User Criteria is the correct and supported mechanism for catalog visibility.

How to eliminate wrong answers

Option A is wrong because User Criteria on a Catalog Category form controls visibility of the category, not an individual catalog item — and the question specifically asks about restricting a catalog item. Option C is wrong because the 'Audience' field on a Service Portal Page record controls which portal page a user sees, not catalog item visibility. Option D is wrong because ACLs on sc_cat_item control record-level read/write access and are not the recommended way to manage catalog item visibility; they can break portal rendering and search.

Practice this question →
91
Multi-Selecthard

Which THREE of the following components are part of the Service Catalog data model? (Choose three.)

Select 3 answers
A.Configuration Item [cmdb_ci]
B.Problem [problem]
C.Catalog Task [sc_task]
D.Request [sc_request]
E.Requested Item [sc_req_item]
AnswersC, D, E

Catalog Task [sc_task] records the fulfilment work generated when a catalog item is ordered, linking the request to its underlying tasks. It forms part of the Service Catalog data model alongside Catalog Item and Category, satisfying the stem's requirement for three valid components rather than unrelated task tables.

Why this answer

In the ServiceNow Service Catalog data model, the three core tables that make up a catalog request are Request [sc_request], Requested Item [sc_req_item], and Catalog Task [sc_task]. Option D, Request [sc_request], is correct because it is the top-level record that groups one or more requested items submitted together in a single catalog order. Option E, Requested Item [sc_req_item], is correct because it represents the individual line item for each catalog item ordered and is the record that drives approval and fulfillment workflows.

Option C, Catalog Task [sc_task], is correct because it is the task record generated against a requested item to carry out the actual fulfillment work. Options A and B are not part of the Service Catalog data model: Configuration Item [cmdb_ci] belongs to the CMDB, and Problem [problem] belongs to ITIL problem management, neither of which is a catalog request component.

Exam trap

CIS-ITSM often tests the distinction between Service Catalog tables and other ITSM tables like CMDB and Problem — candidates incorrectly include cmdb_ci or problem in the Service Catalog data model.

Practice this question →
92
MCQhard

When utilizing Flow Designer to fulfill a Service Catalog request, how should the flow access the variables submitted by the user on the catalog item?

A.By calling a client-side script from the flow action
B.Using a legacy GlideRecord query on sc_item_option_mtom
C.Through the 'Requested Item' record data pill, accessing the 'Variables' section
D.Using system properties configured in the flow inputs
AnswerC

Catalog item variables are stored on the Requested Item (sc_req_item) record, so the flow retrieves them via that record's data pill and its Variables section. This gives the flow the submitted user values it needs to fulfil the request.

Why this answer

In Flow Designer, catalog item variables submitted by the user are accessible through the 'Requested Item' record data pill, which exposes a 'Variables' section containing all the variable values. This is the standard, supported way to reference catalog variables within a flow.

Exam trap

The trap is choosing legacy GlideRecord queries or client-side scripting out of habit — candidates familiar with older ServiceNow patterns may miss that Flow Designer natively exposes catalog variables through the Requested Item data pill.

How to eliminate wrong answers

Option A is wrong because calling a client-side script from a flow action is not how Flow Designer accesses catalog variables — flows run server-side and should use data pills, not client scripts. Option B is wrong because querying sc_item_option_mtom directly with GlideRecord is a legacy, unsupported pattern that bypasses the modern Flow Designer data model and is unnecessary when the Requested Item data pill already exposes variables. Option D is wrong because system properties are global configuration values, not the mechanism for passing catalog item variable data into a flow.

Practice this question →
93
Multi-Selecthard

Which THREE of the following statements are correct regarding Catalog Client Scripts? (Choose three.)

Select 3 answers
A.They execute on the server side during database insert operations.
B.They support script types including onLoad, onChange, and onSubmit.
C.They can use the g_form API to control field visibility and values.
D.They can be written to execute asynchronously using GlideAjax to query server data.
E.They automatically replace workflow activities in defining task assignments.
AnswersB, C, D

Catalog Client Scripts run client-side in the browser, and ServiceNow defines distinct script types for them: onLoad fires when the form loads, onChange when a specified field value changes, and onSubmit before submission. This directly satisfies the stem's requirement for supported script types, confirming the statement as accurate.

Why this answer

Option B is correct because Catalog Client Scripts support the standard client-side script types onLoad (runs when the catalog form loads), onChange (runs when a specified variable changes), and onSubmit (runs when the form is submitted). Option C is correct because Catalog Client Scripts run in the browser and can use the g_form API to manipulate the form, such as hiding/showing variables with g_form.setDisplay() or setting values with g_form.setValue(). Option D is correct because client scripts can call GlideAjax to asynchronously query server-side data without a full page reload, which is a common pattern for retrieving reference or database values in catalog items.

Option A is incorrect because Catalog Client Scripts execute on the client (browser) side, not on the server during database inserts; server-side logic would require a Catalog Script Include, Business Rule, or similar. Option E is incorrect because Catalog Client Scripts do not replace workflow activities; workflows and Flow Designer are separate orchestration mechanisms for task assignments and approvals.

Exam trap

CIS-ITSM often tests the misconception that Catalog Client Scripts run on the server side or can directly manipulate database records, when they are actually client-side and require GlideAjax for server data.

Practice this question →
94
MCQhard

An administrator needs to write an onSubmit Catalog Client Script that validates whether at least one checkbox in a group of ten checkboxes is checked before the item can be added to the cart. Which approach should be used?

A.Write a Client Script on the sc_cart table to intercept the checkout action.
B.Configure a Dictionary Override on the sc_req_item table to enforce mandatory checkboxes.
C.Iterate through the checkbox variable names using g_form.getValue() and return false if none are true, preventing submission.
D.Use document.getElementsByClassName() to count checked elements directly from the DOM.
AnswerC

Iterating with g_form.getValue() across all ten checkbox variables directly satisfies the "at least one checked" constraint, since onSubmit returning false halts submission and displays the mandatory message. This client-side validation runs before the item reaches the cart, catching the empty selection without server round-trips.

Why this answer

An onSubmit Catalog Client Script runs before the item is added to the cart, allowing validation logic to execute. Using g_form.getValue() to iterate through each checkbox variable and checking if at least one is true, then returning false if none are checked, prevents submission and displays an error message. This is the standard client-side validation approach for catalog items.

Exam trap

CIS-ITSM often tests the confusion between client-side validation using g_form API and unsupported DOM manipulation or incorrect table-level scripts, leading candidates to choose DOM-based or sc_cart-based approaches.

How to eliminate wrong answers

Option A is wrong because a Client Script on the sc_cart table intercepts checkout, not the 'Add to Cart' action, and does not validate individual catalog item variables at submission time. Option B is wrong because Dictionary Overrides apply to table fields, not catalog variables, and cannot enforce mandatory checkboxes in a variable group. Option D is wrong because using document.getElementsByClassName() directly manipulates the DOM, which is unsupported in ServiceNow client scripts and breaks with UI changes or platform upgrades.

Practice this question →
95
MCQeasy

Which record type represents the actual fulfillment process of a single catalog item included in a request?

A.Order Guide (sc_cat_item_guide)
B.Catalog Task (sc_task)
C.Service Request (sc_request)
D.Request Item (sc_req_item)
AnswerD

A Request Item (sc_req_item) tracks the fulfilment of one individual catalog item within a parent Request, recording its own state, tasks and approvals. This granularity satisfies the stem's requirement for the actual fulfilment process of a single catalog item, rather than the whole request.

Why this answer

The Request Item (sc_req_item) record represents the fulfillment of a single catalog item within a request. When a user orders a catalog item (or an Order Guide containing multiple items), ServiceNow creates one sc_request record and one sc_req_item per catalog item, and each Request Item drives its own fulfillment workflow and catalog tasks.

Exam trap

CIS-ITSM often tests the confusion between sc_request, sc_req_item, and sc_task — candidates pick the top-level Service Request when the question asks about a single catalog item's fulfillment.

How to eliminate wrong answers

Option A is wrong because an Order Guide (sc_cat_item_guide) is a container that bundles multiple catalog items into a single ordering experience — it is not the fulfillment record for a single item. Option B is wrong because a Catalog Task (sc_task) represents a unit of work assigned to a fulfiller within a Request Item's workflow, not the item-level fulfillment record itself. Option C is wrong because a Service Request (sc_request) is the top-level container that groups one or more Request Items; it represents the overall request, not a single item's fulfillment.

Practice this question →
96
MCQhard

A developer needs to retrieve variable values from a requested item (sc_req_item) inside a Server-side Script Include called by a catalog workflow. Which method is the most reliable way to obtain variable values on the sc_req_item record?

A.current.variable_pool[variable_name]
B.current.variables.variable_name
C.GlideSystem.getProperty('variable_name')
D.gr.getValue('variables')
AnswerB

On a requested item record, the variables object exposes catalogue item variable values directly, so current.variables.variable_name reliably returns them within a Script Include invoked by the workflow, without extra GlideRecord queries against the item option tables.

Why this answer

On an sc_req_item record, the 'variables' field is a GlideElement that exposes the variable pool as an object, so current.variables.variable_name returns the value of the named variable. This is the documented, supported API for reading catalog variables server-side and works consistently in Script Includes, Business Rules, and workflow scripts. It resolves the variable by its internal name and returns the value with the correct type.

Exam trap

The trap here is confusing the raw serialized 'variables' field (getValue) with the parsed variable object (current.variables.x), or assuming a system property or variable_pool exists — candidates who haven't worked with catalog scripting often pick the wrong accessor.

How to eliminate wrong answers

Option A is wrong because 'variable_pool' is not a valid field or property on sc_req_item — the correct container is 'variables'. Option C is wrong because GlideSystem.getProperty reads a system property (sys_properties), not a catalog variable, so it would return unrelated configuration data. Option D is wrong because gr.getValue('variables') returns the raw serialized string of the variable pool, not the parsed value of a specific variable, and is not the reliable way to obtain a single variable's value.

Practice this question →
97
MCQhard

An order guide includes three cascading catalog items. When a user submits the order guide, the values populated in the base order guide prompt variables do not pass to one of the child items. What is the most likely cause of this behavior?

A.The variable names or types between the order guide and the child catalog item do not match exactly.
B.The child catalog item has 'No cart' checked in its Web Service settings.
C.Cascade variables is disabled globally in Service Catalog properties (glide.sc.cascade).
D.The child catalog item uses a multi-row variable set which prevents cascading.
AnswerA

Order guide values propagate to child items only when variable names and types align exactly. A mismatch in either prevents the mapping, so the child receives no inherited value — the specific cause of the described failure.

Why this answer

The most likely cause is that the variable names or types between the order guide and the child catalog item do not match exactly. Order guide cascading relies on matching variable names and types to pass values from the order guide's prompt variables to the child item's variables. If they differ, the values will not populate.

Exam trap

Candidates might blame global settings or MRVS, but the most common issue is mismatched variable names/types; the exam tests attention to configuration details.

How to eliminate wrong answers

Option B is wrong because 'No cart' setting affects whether the item uses a shopping cart, not variable cascading. Option C is wrong because there is no global property 'glide.sc.cascade' that disables cascading; cascading is configured per order guide. Option D is wrong because multi-row variable sets do not inherently prevent cascading; they can be used with cascading if variables match.

Practice this question →
98
MCQhard

A custom Service Catalog workflow encounters an error where a 'Run Script' activity fails to complete because it attempts to query the sc_cart table instead of the requested item. What is the proper table object to query for submitted request items within a workflow?

A.sc_cart
B.sys_user_has_role
C.sc_req_item
D.sc_request
AnswerC

The sc_req_item table stores individual requested items generated from a submitted request, so a workflow querying it retrieves the correct catalogue item records. The sc_cart table holds pre-submission shopping cart contents, which is why that query fails to return the submitted items.

Why this answer

The sc_req_item table (Requested Item) is the correct table to query for individual submitted request items within a workflow. Each requested item represents a line item in a request and contains the catalog item details and variables.

Exam trap

The trap is confusing the shopping cart table (sc_cart) with the submitted requested item table (sc_req_item), so candidates must remember that sc_cart is transient and not used in workflows.

How to eliminate wrong answers

Option A is wrong because sc_cart is a temporary table used for the shopping cart before submission; it is not used for submitted request items. Option B is wrong because sys_user_has_role is a table storing user role assignments, unrelated to request items. Option D is wrong because sc_request is the parent request record that can contain multiple requested items; querying it would not give individual item details.

Practice this question →
99
Multi-Selecteasy

Which TWO actions can a Catalog UI Policy perform on catalog item variables without writing code? (Choose two.)

Select 2 answers
A.Make variables mandatory or optional
B.Automatically compile Java source code
C.Delete user profile records
D.Create new database tables
E.Make variables visible or hidden
AnswersA, E

Catalog UI Policies can dynamically set variables to mandatory or optional.

Why this answer

Catalog UI Policies are no-code configuration records in ServiceNow that dynamically control the behavior of catalog item variables on the form. Option A is correct because a Catalog UI Policy can set a variable's Mandatory field to true or false, forcing or removing the requirement that the user supply a value before submission. Option E is correct because the same policy can toggle a variable's Visible field, showing or hiding it based on conditions such as the value of another variable.

The remaining options are incorrect: compiling Java source code (B) is a development activity unrelated to UI policies, deleting user profile records (C) is a data operation performed by users or scripts, and creating new database tables (D) is a schema change done through table administration, none of which a Catalog UI Policy can do.

Exam trap

CIS-ITSM often tests the boundary between no-code UI Policies and code-required Client Scripts, so candidates who think any dynamic behavior needs JavaScript pick wrong options.

Practice this question →
100
MCQmedium

An administrator is configuring a Record Producer that allows end users to submit a Facilities request. Which table should be selected as the target table for this record producer?

A.Cart [sc_cart]
B.Catalog Item [sc_cat_item]
C.Requested Item [sc_req_item]
D.Target functional table (e.g., Facilities [x_facilities_task])
AnswerD

A Record Producer must target a functional table that stores the resulting records, such as a custom Facilities task table. Selecting the functional table ensures submitted requests create properly structured task records rather than landing on an unrelated or non-task table.

Why this answer

A Record Producer's purpose is to create records directly on a target functional table (like Facilities [x_facilities_task]) rather than going through the standard catalog request/requested-item flow. The target table field on the Record Producer determines which table the submitted record is inserted into, so for a Facilities request the correct target is the Facilities task table.

Exam trap

The trap here is confusing the Record Producer's target table with the catalog infrastructure tables (sc_cart, sc_cat_item, sc_req_item) that standard catalog items use — candidates must remember Record Producers write directly to a functional table.

How to eliminate wrong answers

Option A is wrong because Cart [sc_cart] is a transient staging table for catalog checkout, not a destination for record producer output. Option B is wrong because Catalog Item [sc_cat_item] defines the catalog entry itself, not the record produced when a user submits the producer. Option C is wrong because Requested Item [sc_req_item] is used by standard catalog items to track fulfillment, but Record Producers bypass this and write directly to a functional table.

Practice this question →
101
MCQmedium

An administrator wants to hide a variable set on a catalog item form when a checkbox variable is unchecked. Where should this behavior be configured?

A.Catalog UI Policy
B.Catalog Client Script (onLoad)
C.Workflow properties
D.Order Guide Rule Base
AnswerA

Catalog UI Policies control field visibility, mandatory and read-only behaviour on catalog item forms, driven by conditions on other variables. A policy with the condition that the checkbox is false, and an action setting the variable set to not visible, hides it dynamically without scripting.

Why this answer

A Catalog UI Policy is the correct mechanism to hide a variable set when a checkbox variable is unchecked. UI Policies provide declarative, no-code control over field visibility, mandatory, and read-only states on catalog forms, and they support conditions based on other variables. The policy's action would target the variable set (or its contained variables) and set 'Visible = false' when the checkbox is false.

Exam trap

The trap is choosing a client script because it feels more flexible — candidates often overlook that UI Policies are the declarative, supported way to hide fields based on other field values, and client scripts are reserved for logic UI Policies cannot express.

How to eliminate wrong answers

Option B is wrong because a Catalog Client Script (onLoad) runs only once when the form loads and does not automatically re-evaluate when the checkbox changes — you would need an OnChange script instead, and even then UI Policy is the declarative best practice. Option C is wrong because workflow properties control fulfillment behavior after submission, not form field visibility during ordering. Option D is wrong because 'Order Guide Rule Base' is not a standard ServiceNow configuration for hiding variables on a catalog item form — order guides have their own inclusion rules, but they govern which items appear in the guide, not variable visibility within an item.

Practice this question →
← PreviousPage 2 of 2 · 101 questions total

Ready to test yourself?

Try a timed practice session using only Service Catalog And Request Management questions.

Start 20-question session