Courseiva

CCNA Service Catalog Workflows Questions

61 questions · Service Catalog Workflows topic · All types, answers revealed

Practice these questionsExam hubAll questions
1
MCQhard

A catalog item uses Flow Designer to send an email notification when the state changes to 'fulfilled'. The flow uses a trigger 'State changed' on the requested item table. However, the email is not sent. The flow logs show the trigger fired. What is the most likely issue?

A.The flow action 'Send Email' is not configured with a valid recipient
B.The trigger is set to 'State changed' but the state field is not properly referenced
C.The flow is set to 'Deactivated'
D.The email notification is blocked by an email property
AnswerA

The action may lack a recipient, causing it to fail silently.

Why this answer

Option A is correct because the most common reason a flow trigger fires but the email is not sent is that the 'Send Email' action lacks a valid recipient. In Flow Designer, the 'Send Email' action requires a recipient (e.g., user, group, or email address) to be explicitly defined; if the recipient field is empty or references a non-existent variable, the action will execute without sending the email, and no error will be logged in the flow logs.

Exam trap

The trap here is that candidates assume a fired trigger guarantees the email was attempted, but they overlook that the 'Send Email' action can complete without sending if the recipient is missing, and the flow logs will not show a failure for that action.

How to eliminate wrong answers

Option B is wrong because the flow logs show the trigger fired, which means the state field was properly referenced and the condition was met; if the state field were not properly referenced, the trigger would not have fired. Option C is wrong because if the flow were deactivated, the trigger would not fire at all, and the flow logs would not show the trigger firing. Option D is wrong because email properties (e.g., glide.email.smtp.enable) block all outbound email globally, not just for a specific flow; if an email property were blocking, the flow logs would typically show an error or the email would fail for all flows, not just this one.

Practice this question →
2
MCQeasy

A catalog item has a variable with a mandatory condition: if the variable 'category' is 'software', then 'software name' is mandatory. This is best implemented using:

A.UI Policy
B.Catalog Client Script
C.ACL
D.Variable Condition
AnswerA

UI policies are designed for conditional mandatory, visibility, etc.

Why this answer

A UI Policy is the correct choice because it allows you to define a mandatory condition on a catalog item variable without writing any code. In this case, you would create a UI Policy that runs when the 'category' variable is 'software', and within that policy set the 'software name' variable's mandatory attribute to true. This is the standard, no-code approach for enforcing variable-level mandatory conditions in Service Catalog.

Exam trap

The trap here is that candidates often confuse 'Variable Condition' (which controls visibility) with 'UI Policy' (which controls mandatory, read-only, and visibility), leading them to pick D instead of A.

How to eliminate wrong answers

Option B (Catalog Client Script) is wrong because client scripts are used for client-side validation or dynamic behavior, but they require JavaScript and are not the recommended method for simply making a variable mandatory based on another variable's value; UI Policy is the declarative, no-code alternative. Option C (ACL) is wrong because Access Control Lists govern data access permissions (read/write/delete) on records, not form-level variable behavior like mandatory conditions. Option D (Variable Condition) is wrong because variable conditions are used to show or hide variables, not to enforce mandatory status; they control visibility, not requiredness.

Practice this question →
3
MCQeasy

Refer to the exhibit. A catalog client script with the above code runs on load of a catalog item. Which statement is true?

A.The category variable will be set to 'software' only if the user does not change it.
B.The script will run on every page load and set the category to 'software'.
C.The script will cause an error because onLoad should use g_form.setDisplay.
D.The script will only run if the variable 'category' is visible.
AnswerB

onLoad runs each time the form loads, unconditionally setting the value.

Why this answer

Option B is correct because the `onLoad` catalog client script runs every time the catalog item form is loaded, and the code `g_form.setValue('category', 'software')` unconditionally sets the category field to 'software' on each load. This overrides any previous value or user input from a prior session, ensuring the field is always set to 'software' when the form renders.

Exam trap

ServiceNow often tests the distinction between `onLoad` (runs every time the form loads) and `onChange` (runs only when a specific field changes), leading candidates to mistakenly think `onLoad` scripts run only under certain conditions like user interaction or field visibility.

How to eliminate wrong answers

Option A is wrong because the script runs on every load and sets the category to 'software' regardless of whether the user changes it; the user's change would be overwritten on the next load, not preserved. Option C is wrong because `g_form.setValue` is the correct method for setting a field's value in an `onLoad` client script; `g_form.setDisplay` controls visibility, not value assignment, and no error occurs. Option D is wrong because the script executes on every page load irrespective of the field's visibility; visibility does not affect the execution of `onLoad` scripts.

Practice this question →
4
Multi-Selecthard

Which TWO of the following are true about catalog client scripts in ServiceNow?

Select 2 answers
A.They use GlideRecord to query data.
B.They can run on both client and server.
C.They are defined per catalog item only.
D.They can be triggered on load, onChange, or onSubmit.
E.They can access the g_form API.
AnswersD, E

These are the standard trigger points for catalog client scripts.

Why this answer

Option D is correct because catalog client scripts can be triggered on three specific events: onLoad (when the form loads), onChange (when a field value changes), and onSubmit (when the form is submitted). These triggers allow dynamic client-side behavior such as field validation, auto-population, or conditional visibility without requiring a server round-trip.

Exam trap

The trap here is confusing catalog client scripts with catalog UI policies: candidates often think client scripts can use GlideRecord (server-side) or run on the server, but ServiceNow enforces a strict client-server separation where client scripts cannot access server-side APIs directly.

Practice this question →
5
MCQhard

A catalog item uses a 'Catalog Client Script' to hide a variable when another variable is set to 'No'. However, the script is not working. The script is of type 'onChange' and the variable to hide is a 'Single Line Text'. What is the most likely cause?

A.The variable type 'Single Line Text' does not support hiding.
B.The script is missing a 'g_form.setDisplay()' call.
C.The script should be of type 'onSubmit' instead of 'onChange'.
D.The variable's 'Display' property is set to 'Static' or 'Read only'.
AnswerD

If Display is static, client scripts cannot hide it.

Why this answer

Option D is correct because when a variable's 'Display' property is set to 'Static' or 'Read only', the client-side script cannot override that setting via `g_form.setDisplay()`. The catalog client script runs on the client, but the variable's display behavior is enforced by the platform's UI policy layer, which takes precedence over client script calls. This is a common misconfiguration where the variable's display property is locked, preventing the onChange script from hiding it.

Exam trap

ServiceNow often tests the misconception that a missing `g_form.setDisplay()` call is the root cause, when in reality the variable's display property is locked by a UI policy or the variable's own configuration, which silently overrides the client script.

How to eliminate wrong answers

Option A is wrong because 'Single Line Text' variables fully support hiding via client scripts; there is no restriction on variable type for hiding. Option B is wrong because while `g_form.setDisplay()` is the correct method to hide a variable, the issue is not its absence but rather the variable's display property overriding the script's attempt. Option C is wrong because an 'onSubmit' script runs at form submission, not on variable change, so it would not dynamically hide the variable when the triggering field changes; 'onChange' is the correct type for this behavior.

Practice this question →
6
MCQhard

Refer to the exhibit. A ServiceNow administrator created a catalog item that allows users to select a CI via a reference variable named 'ci'. The business rule shown is supposed to update the CI's operational status to 'In Production' when the requested item is closed complete. However, the CI status is not being updated. What is the most likely cause?

A.The condition 'current.state.changesTo(3)' is incorrect; it should check if the state is already 3.
B.The script does not properly retrieve the CI record because current.variables.ci returns the sys_id but may not be accessible directly in an after business rule without using the sc_item_option table.
C.The reference variable 'ci' is not storing the sys_id of the CI; it stores the display value.
D.The business rule runs 'Before' instead of 'After', so the state hasn't changed yet.
AnswerB

Correct: Variable values are stored in the sc_item_option table and may not be directly accessible via current.variables in an after business rule. The script should use a GlideRecord query on sc_item_option.

Why this answer

Option B is correct because in an 'after' business rule on the Requested Item (sc_req_item) table, the variable values from the catalog item are not directly accessible via current.variables.ci. Instead, they are stored in the sc_item_option table and must be retrieved using a GlideRecord query on sc_item_option joined to the requested item's sys_id. The script attempts to use current.variables.ci, which does not resolve to the CI's sys_id in this context, causing the update to fail.

Exam trap

The trap here is that candidates assume current.variables.ci works in all server-side scripts, but ServiceNow restricts direct variable access to catalog client scripts and workflows, not business rules on the requested item table.

How to eliminate wrong answers

Option A is wrong because current.state.changesTo(3) is a valid condition that triggers when the state changes to 3 (Closed Complete); checking if the state is already 3 would not capture the transition. Option C is wrong because a reference variable stores the sys_id of the referenced record, not the display value, so the variable itself is not the issue. Option D is wrong because the business rule runs 'After' (as indicated by the 'after' keyword in the exhibit), so the state has already changed; running 'Before' would prevent the state change from being committed.

Practice this question →
7
MCQmedium

A large enterprise uses ServiceNow for IT service management. They have a catalog item 'New Employee Setup' that is used by HR to request IT resources for new hires. The catalog item includes variables for employee name, start date, department, and manager. The workflow associated with this item creates a catalog task for the desktop team to prepare a laptop, and another catalog task for the network team to create accounts. Recently, the desktop team has been receiving tasks with incomplete information; the employee name variable is sometimes empty even though it is marked as mandatory. The administrator checked the variable definition and confirmed 'Mandatory' is set to 'true'. The variable is a 'Single Line Text' with no default value. The issue happens intermittently. What course of action should the administrator take to resolve this issue?

A.Add a workflow script activity that checks if the variable is empty and rejects the request if so.
B.Reorder the workflow activities so that the validation occurs earlier.
C.Change the variable type to 'Email' to enforce stronger validation.
D.Set the variable to 'Read only' and populate it from a reference field.
AnswerA

Server-side validation ensures data integrity even if client-side checks fail.

Why this answer

Option A is correct because the issue is that the mandatory field validation is being bypassed intermittently, likely due to the catalog item being submitted via a web service, REST API, or an integration where client-side mandatory checks are not enforced. Adding a workflow script activity that checks the variable value server-side ensures that even if the client-side validation fails, the request is rejected before proceeding, providing a reliable server-side guard.

Exam trap

The trap here is that candidates assume mandatory fields are always enforced server-side, but ServiceNow's mandatory attribute is primarily client-side, and the exam tests the understanding that server-side validation in a workflow is needed for scenarios like API submissions or intermittent bypasses.

How to eliminate wrong answers

Option B is wrong because reordering workflow activities does not address the root cause; the mandatory field validation is a client-side check that occurs before the workflow starts, so moving activities within the workflow will not enforce server-side validation. Option C is wrong because changing the variable type to 'Email' only changes the input format validation (e.g., requiring an '@' symbol), but it does not enforce that the field is non-empty; the mandatory attribute is still client-side and can be bypassed. Option D is wrong because setting the variable to 'Read only' and populating it from a reference field would prevent manual entry but does not solve the intermittent empty value issue; it also changes the data source and may not align with the requirement for free-text entry.

Practice this question →
8
MCQeasy

A ServiceNow administrator is designing a catalog workflow that requires approval from the user's manager only if the total cost of the request exceeds $500. Which workflow configuration should be used?

A.Add an Approval - Group activity and set the 'Approval Group' to 'Manager's Group'.
B.Set the variable 'total_cost' as 'Required If' a condition.
C.Add an Approval - User activity with a Condition that checks if the variable 'total_cost' is greater than 500.
D.Use an Approval Group activity and add the manager as a member.
AnswerC

This allows the approval to be conditional based on cost.

Why this answer

Option C is correct because the Approval - User activity allows you to specify a single user (the manager) and attach a condition that evaluates the 'total_cost' variable. When the condition is true (total_cost > 500), the approval activity runs; otherwise, it is skipped. This directly implements the requirement for manager approval only when the cost exceeds $500.

Exam trap

The trap here is that candidates often confuse 'Required If' variable conditions with workflow approval conditions, or assume that an Approval Group activity can be used for a single user by adding them as a member, but neither approach provides the conditional logic needed to trigger approval only when cost exceeds $500.

How to eliminate wrong answers

Option A is wrong because an Approval - Group activity sends the request to an entire group (e.g., 'Manager's Group'), not to the specific manager of the user, and it lacks a condition to trigger only when cost exceeds $500. Option B is wrong because setting a variable as 'Required If' only controls whether the variable must be filled in, not whether an approval step runs; it does not add any approval logic. Option D is wrong because an Approval Group activity (like Option A) requires a group, not a single user, and adding the manager as a member does not create a conditional approval based on cost.

Practice this question →
9
Multi-Selecthard

Which TWO of the following are valid ways to trigger a workflow from a catalog item? (Choose two.)

Select 2 answers
A.On the catalog item form, go to the 'Workflow' tab and select a workflow.
B.Write a Business Rule on the 'sc_request' table that starts a workflow.
C.Set the 'Workflow' field on the catalog item to the desired workflow.
D.In the workflow editor, add a 'Execute Workflow' activity pointing to the catalog item.
E.Create a Flow in Flow Designer that triggers on 'Record Created' for the 'Request' table.
AnswersC, E

The Workflow field directly associates a workflow.

Why this answer

Option C is correct because the 'Workflow' field on the catalog item record directly associates a workflow with that item. When a user submits the catalog item, the platform automatically triggers the associated workflow on the generated sc_request record. This is the standard declarative method for linking a catalog item to a workflow without custom scripting.

Exam trap

The trap here is that candidates often confuse the 'Workflow' tab (which does not exist) with the 'Workflow' field, or they think a Business Rule on the sc_request table is a direct catalog item trigger, when it is actually a secondary scripted method not listed as a valid direct trigger in the exam objectives.

Practice this question →
10
MCQhard

A catalog item uses a workflow that includes a 'Wait for Condition' activity. The condition checks if a custom table record 'approval_status' equals 'approved'. Requests are not progressing past this activity even though the record is updated. What could be the issue?

A.The 'Wait for Condition' activity is not in the same application scope as the custom table.
B.The user updating the record does not have the 'workflow_admin' role.
C.The 'Check Condition' property of the activity is set to 'After Update', but the record was already updated before the workflow reached this activity.
D.The custom table record is not related to the catalog item.
AnswerC

Activity only evaluates when the record is updated after it begins waiting.

Why this answer

Option C is correct because the 'Wait for Condition' activity's 'Check Condition' property determines when the condition is evaluated. If set to 'After Update', the condition is only checked when the record is updated after the workflow reaches this activity. If the record was already updated before the workflow reached the 'Wait for Condition' activity, the condition will never be re-evaluated, causing the workflow to stall indefinitely.

Exam trap

ServiceNow often tests the nuance of the 'Check Condition' property timing, where candidates assume the condition is evaluated immediately upon reaching the activity, ignoring that the 'After Update' setting requires a subsequent update event to trigger re-evaluation.

How to eliminate wrong answers

Option A is wrong because the 'Wait for Condition' activity does not require being in the same application scope as the custom table; scoping affects access to tables but not the condition evaluation logic. Option B is wrong because the 'workflow_admin' role is not required to update a record that triggers a workflow condition; any user with write access to the table can update the record, and the workflow engine evaluates conditions based on the record state, not the user's role. Option D is wrong because the custom table record does not need to be directly related to the catalog item; the 'Wait for Condition' activity can check any table record as long as the condition is properly defined, and the workflow context provides the record's sys_id.

Practice this question →
11
Multi-Selectmedium

Which THREE are valid ways to bring data into a catalog item variable?

Select 3 answers
A.Lookup select box that references a table
B.Workflow context variable
C.Record producer variable mapping
D.Catalog client script on submit
E.Variable default value from a script
AnswersA, C, E

Choices from a lookup select box populate the variable with values from a table.

Why this answer

Option A is correct because a Lookup Select Box variable type can be configured to reference a table, allowing the user to select a record from that table, which brings data into the variable. This is a standard way to populate a catalog item variable with data from a ServiceNow table, such as selecting a user from the sys_user table.

Exam trap

The trap here is that candidates often confuse client-side scripts (like on submit) with data population mechanisms, thinking they can bring data into a variable, when in fact they only modify or validate existing variable values after the variable is already populated.

Practice this question →
12
MCQmedium

A company has a catalog item 'Travel Authorization' with a workflow that requires approval from the user's manager and the finance department if the travel cost is above $1000. The workflow is set up with two 'Approval - User' activities: one for the manager and one for a finance user. However, when a request with cost $1500 is submitted, only the manager approval is triggered; the finance approval is skipped. The workflow has a condition on the finance approval activity that checks 'variable_cost > 1000'. The variable 'cost' is defined as a monetary value and is being passed correctly. What is the most likely cause?

A.The condition on the finance approval activity uses the variable while the workflow is still in the 'default' stage before variable values are committed.
B.The 'cost' variable has a default value of 0, so the condition never passes.
C.The 'Approval - User' for finance is placed before the manager approval in the workflow.
D.The workflow is configured with a 'Starting Condition' that blocks the finance activity.
AnswerA

The variable may not be fully committed when the workflow first evaluates the condition. Ensure the condition references the request item's variable correctly after submission.

Why this answer

The most likely cause is that the condition on the finance approval activity is evaluated while the workflow is still in the 'default' stage, before the variable values from the catalog item request are committed. In ServiceNow, workflow variables are not populated until the workflow enters the appropriate stage or the variable is explicitly set. Since the condition checks 'variable_cost > 1000' but the variable hasn't been assigned yet, the condition evaluates to false, causing the finance approval to be skipped.

Exam trap

The trap here is that candidates assume variables are immediately available in the workflow, but ServiceNow delays variable commitment until after the default stage, causing conditions to fail silently.

How to eliminate wrong answers

Option B is wrong because if the 'cost' variable had a default value of 0, the condition 'variable_cost > 1000' would still evaluate to false, but the core issue is that the variable is not yet committed, not its default value. Option C is wrong because the order of approval activities does not affect whether a condition is evaluated; the condition on the finance activity is evaluated independently of its position relative to the manager approval. Option D is wrong because a 'Starting Condition' would prevent the entire workflow from starting, not selectively skip a single activity; the workflow is running and the manager approval is triggered, so no starting condition is blocking the finance activity.

Practice this question →
13
Matchingmedium

Match each ServiceNow user role to its typical permission.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Full access to all records and configurations

Access to ITIL processes like incident, problem, change management

ServiceNow internal use, not assigned to customers

Basic access to create and view own records

Manage service catalog items and categories

Why these pairings

Roles control what users can see and do in ServiceNow.

Practice this question →
14
Multi-Selecteasy

Which TWO of the following are valid ways to add variables to a catalog item?

Select 2 answers
A.Variable Set
B.Catalog Client Script
C.Variable Editor
D.Order Guide
E.UI Policy
AnswersA, C

Variable sets allow adding predefined groups of variables to a catalog item.

Why this answer

Option A is correct because Variable Sets are a primary method for grouping and adding multiple variables to a catalog item, allowing reuse across items. Option C is correct because the Variable Editor is the direct interface within a catalog item's record where you define and add individual variables to the item's variable list.

Exam trap

The trap here is that candidates often confuse UI Policies or Catalog Client Scripts with the ability to add variables, when in fact they only modify the behavior of variables that already exist on the catalog item.

Practice this question →
15
MCQhard

Refer to the exhibit. A server provisioning request is in progress. The network configuration task is waiting for the VM creation task to provide an IP address, but no IP is passed. What is the most likely cause?

A.The IP address is manually entered by the VM team and they forgot to update it.
B.The network team does not have access to the VM task output.
C.The VM creation task did not run successfully despite being closed complete.
D.The flow did not capture the output variable from the VM creation task and pass it to the network task.
AnswerD
Practice this question →
16
MCQhard

Refer to the exhibit. A workflow includes a 'Run Script' activity with the above configuration. What will happen when the workflow reaches this activity?

A.The script will cause an error because current is not defined in workflow.
B.The script runs but current.update() is unnecessary because state is set automatically.
C.The script runs and updates the current record's state to pending.
D.The script only runs when the workflow is started, not when the activity is reached.
AnswerC

The script uses current to set state and update the record.

Why this answer

Option C is correct because the 'Run Script' activity in a ServiceNow workflow executes the provided script when the workflow reaches that activity. The script uses the 'current' GlideRecord object, which is automatically available in workflow scripts and represents the record that triggered the workflow. The 'current.state = 3' line sets the state field to the value for 'pending' (typically 3 in the standard incident or task table), and 'current.update()' commits this change to the database, so the record's state is updated to pending.

Exam trap

The trap here is that candidates assume 'current.update()' is optional or that 'current' is not available in workflow scripts, when in fact it is always available and update() is required to save changes.

How to eliminate wrong answers

Option A is wrong because 'current' is a predefined variable in ServiceNow workflow scripts, representing the record that triggered the workflow, so it is always defined. Option B is wrong because 'current.update()' is necessary to persist the state change to the database; setting the field value alone does not commit the change. Option D is wrong because the 'Run Script' activity executes the script each time the workflow reaches that activity, not only when the workflow is started.

Practice this question →
17
MCQeasy

A record producer is configured to create a task when a user submits a form from the service portal. The task is created but the variables from the form are not mapped. What is the most likely cause?

A.The record producer's mandatory fields are not all filled
B.The target table does not have the same fields as the source
C.The 'Variable mapping' section of the record producer is not configured
D.The service portal is not configured to pass variables to the record producer
AnswerC

Variable mapping specifies which source fields map to which target fields.

Why this answer

The record producer's 'Variable mapping' section is responsible for explicitly mapping form variables to fields on the target table. When this section is left unconfigured, the system creates the task record but does not transfer variable values from the service portal form, even if the form is submitted successfully. This is a common oversight because the record producer itself is triggered correctly, but the variable data is not passed without explicit mapping.

Exam trap

The trap here is that candidates assume the service portal automatically passes variable values to the target table fields, but ServiceNow requires explicit variable mapping in the record producer to transfer form data to the task record.

How to eliminate wrong answers

Option A is wrong because mandatory fields being unfilled would prevent the record producer from creating the task at all, not create it without variable mapping. Option B is wrong because the target table does not need to have the same fields as the source; variable mapping is what bridges the form variables to target table fields, and mismatched field names are handled by mapping, not by field existence. Option D is wrong because the service portal inherently passes all form variables to the record producer upon submission; the issue is that the record producer is not configured to consume those variables via the Variable mapping section.

Practice this question →
18
Multi-Selectmedium

Which TWO scenarios would require a Catalog UI Policy instead of a Catalog Client Script?

Select 2 answers
A.Displaying a warning message when a variable is invalid
B.Hiding a variable based on another variable's value
C.Setting a variable's value from a record producer mapping
D.Making a variable read-only after the catalog item is submitted
E.Making a variable mandatory only when a condition is met
AnswersB, E

UI Policy can control visibility declaratively without scripting.

Why this answer

Catalog UI Policies are server-side scripts that run before the form is rendered, making them ideal for conditionally hiding variables based on other variable values. Unlike Catalog Client Scripts, which run client-side and can be bypassed, UI Policies enforce visibility and mandatory rules on the server, ensuring compliance even if JavaScript is disabled.

Exam trap

ServiceNow often tests the misconception that UI Policies can show messages or set values, when in fact they only control visibility, mandatory, and read-only states, while messages and value setting require Client Scripts or other mechanisms.

Practice this question →
19
MCQmedium

A catalog item variable has a reference qualifier that limits the choices to active users only. However, users can still select inactive users. What is the most likely cause?

A.The variable is set to allow 'any' value
B.The user has admin role and ignores qualifier
C.The reference qualifier uses JavaScript that runs on the client but not server
D.The reference qualifier is written incorrectly
AnswerC

If the qualifier is not enforced server-side, client-side scripts can bypass it.

Why this answer

Option C is correct because reference qualifiers that use client-side JavaScript (e.g., g_form.getReference) are evaluated on the client, but the server-side validation that enforces the qualifier during submission does not re-run that client-side logic. This means the qualifier may appear to work in the UI but is not enforced when the record is saved, allowing inactive users to be selected if the client-side script fails or is bypassed.

Exam trap

The trap here is that candidates assume a reference qualifier that works in the UI is always enforced on submission, but ServiceNow's client-server architecture means client-side scripts in qualifiers are not re-evaluated server-side, leading to a false sense of security.

How to eliminate wrong answers

Option A is wrong because setting a variable to allow 'any' value removes all restrictions, but the question states the reference qualifier is present and limits choices to active users, so the issue is not about allowing any value. Option B is wrong because admin roles do not ignore reference qualifiers on catalog item variables; admins may bypass ACLs but reference qualifiers are enforced for all users unless explicitly overridden. Option D is wrong because the qualifier is written correctly (it limits to active users in the UI), but the problem is that it is not enforced server-side, not that the syntax is incorrect.

Practice this question →
20
MCQhard

Refer to the exhibit. A user submits a Laptop Request but receives the error shown. The user's session does not have a location set. What is the most likely cause?

A.The user's role does not have access to u_location variable.
B.The flow is incorrectly configured to require u_location before submission.
C.The catalog item is configured to use a mandatory variable without a default value.
D.The variable u_location is missing from the catalog item form.
AnswerC
Practice this question →
21
Multi-Selecthard

Which TWO conditions are necessary for a catalog item to trigger a workflow automatically upon submission?

Select 2 answers
A.The workflow must be in 'Published' state
B.The catalog item must be in a category that allows workflow execution
C.The workflow must be subscribed to the catalog item
D.The workflow must contain a 'Begin' activity
E.The catalog item's 'Workflow' field must be populated with a workflow
AnswersA, E

Only published workflows can execute.

Why this answer

Option A is correct because a workflow must be in the 'Published' state to be available for execution. Only published workflows can be triggered automatically by a catalog item submission. Option E is correct because the catalog item's 'Workflow' field must be explicitly populated with a reference to a workflow; otherwise, no workflow will be associated with the item, and no automatic trigger will occur.

Exam trap

The trap here is that candidates often think a workflow must be 'subscribed' to the catalog item (Option C) or that a 'Begin' activity is mandatory (Option D), but ServiceNow uses a direct reference from the catalog item to the workflow, and the workflow can start with any activity type.

Practice this question →
22
MCQhard

An administrator notices that a catalog client script is not firing when a variable changes. The script is set to 'onChange' and the variable reference is correct. The script uses g_form.setValue to update another variable. However, the other variable does not get updated. What could be the issue?

A.The variable being updated has a catalog client script that clears it
B.The other variable's value is protected by a UI policy
C.The script is running on the server side
D.The script is using g_form.setValue incorrectly for that variable type
AnswerA

If the target variable has an onChange script that sets its value back, it will override the change.

Why this answer

Option A is correct because when a catalog client script uses g_form.setValue to update another variable, that action triggers the onChange event for the target variable. If the target variable has its own onChange catalog client script that clears its value, that script will execute after the setValue, effectively overriding the update. This creates a conflict where the first script sets a value, but the second script immediately clears it, resulting in the variable appearing unchanged.

Exam trap

The trap here is that candidates assume g_form.setValue always works without side effects, but they forget that setting a value programmatically triggers the onChange event of the target variable, which can execute another script that overrides the change.

How to eliminate wrong answers

Option B is wrong because UI policies do not protect variable values from being changed by client scripts; they only control visibility, mandatory status, or read-only state based on conditions, and a read-only UI policy would prevent the user from editing the field but g_form.setValue can still update it programmatically. Option C is wrong because the script is explicitly set to 'onChange' and runs on the client side (catalog client scripts are client-side by default), so it is not running on the server side. Option D is wrong because g_form.setValue is a standard method that works for all variable types in Service Catalog; there is no incorrect usage specific to variable types that would silently fail without an error.

Practice this question →
23
MCQhard

Refer to the exhibit. A catalog item has a variable 'department' (choice list with values 'IT', 'HR', 'Finance') and a variable 'cost_center' (choice list initially empty). The client script is supposed to add an option to 'cost_center' when 'department' is set to 'IT'. However, when a user selects 'IT', no new option appears. What is the most likely reason?

A.The variable 'cost_center' is not a 'Choice' variable type.
B.The script is a server-side script and cannot use 'g_form'.
C.The script needs to call 'g_form.clearOptions()' before adding options.
D.The method should be 'g_form.addOption()' with different syntax.
AnswerA

addOption only works on choice-type variables.

Why this answer

Option A is correct because the `g_form.addOption()` method only works on variables of type 'Choice' (or similar select-type variables like 'Select Box'). If 'cost_center' is not a Choice variable, the client script cannot dynamically add options to it, and the method call silently fails or has no effect. In ServiceNow, only choice-based variable types support runtime option manipulation via client-side APIs.

Exam trap

The trap here is that candidates assume any variable with a choice list is a 'Choice' variable, but ServiceNow distinguishes between the variable type (which must be 'Choice') and the presence of choice records; the `g_form.addOption()` method only works on variables with the correct underlying type.

How to eliminate wrong answers

Option B is wrong because the script is described as a client script, and `g_form` is a client-side API available in client scripts, catalog client scripts, and UI policies; it cannot be used in server-side scripts, but here the context implies client-side execution. Option C is wrong because `g_form.clearOptions()` is not required before adding options; `g_form.addOption()` can add options to an existing list without clearing it first, and clearing is only needed if you want to replace all options. Option D is wrong because `g_form.addOption()` is the correct method name and syntax for adding an option to a choice variable in a client script; the issue is not with the method name or syntax but with the variable type not supporting dynamic options.

Practice this question →
24
MCQeasy

A multinational company has implemented a Service Catalog to streamline IT requests. The catalog item 'New Laptop Request' includes a workflow that routes approvals based on the cost center of the requester. Recently, several requests submitted by employees in the Finance department are stuck in 'Submitted' state without any approval activity. The workflow has a condition that checks the variable 'cost_center' and if it equals 'Finance', the approval is sent to the Finance manager. Other requests from departments like HR and Marketing proceed normally. The administrator has verified that the 'Finance' cost center value is correctly entered on the requests, the users have appropriate roles, and the approval assignments are active. What is the most likely cause of the issue?

A.The approval rule should be changed to auto-approve for Finance.
B.The workflow approval timeout is set too short and needs to be increased.
C.The catalog item should be reconfigured to not use a workflow.
D.The workflow condition that triggers the Finance approval stage is not evaluating correctly.
AnswerD

If the condition fails, the workflow may not proceed to the approval stage, leaving requests in 'Submitted'.

Why this answer

The issue is that the workflow condition checking the 'cost_center' variable for 'Finance' is not evaluating correctly, causing the approval stage to be skipped or not triggered. Since other departments work fine, the workflow logic itself is likely flawed—perhaps due to a data type mismatch (e.g., comparing a string to a different type) or a typo in the condition script. The administrator has verified data entry, roles, and approval assignments, so the root cause is the condition logic in the workflow.

Exam trap

ServiceNow often tests the misconception that approval assignment or user roles are the cause, when the real issue is a logic error in the workflow condition that prevents the approval stage from being reached.

How to eliminate wrong answers

Option A is wrong because auto-approving Finance requests would bypass the required manager approval, which is not a fix for a broken condition; it changes business process. Option B is wrong because a timeout would cause requests to move to a 'Timed Out' or 'Cancelled' state, not remain stuck in 'Submitted' without any approval activity. Option C is wrong because removing the workflow would eliminate all routing logic, including the working approvals for HR and Marketing, and does not address the specific condition failure.

Practice this question →
25
Multi-Selecthard

Which THREE of the following are valid workflow activities in a Service Catalog workflow? (Choose three.)

Select 3 answers
A.Approval - Dynamic
B.Scrum Task
C.Run Script
D.Wait for Condition
E.Approval - User
AnswersC, D, E

Run Script executes server-side code.

Why this answer

Run Script is a valid workflow activity in ServiceNow Service Catalog workflows. It allows you to execute a script (JavaScript) during the workflow, enabling custom logic such as updating records, calling APIs, or performing calculations. This activity is part of the standard workflow activities available in the Workflow Editor.

Exam trap

The trap here is that candidates confuse 'Approval - Dynamic' with a real activity name, but ServiceNow only has 'Approval - User' and 'Approval - Group' as standard approval activities, and 'Dynamic' refers to how the approver is determined, not the activity name.

Practice this question →
26
MCQmedium

During a workflow, a catalog item's quantity variable 'qty' must be validated to be between 1 and 10. If the value is outside this range, the request should be rejected with a message. Which approach should the administrator take?

A.Add a 'Before Order' script in the catalog item that validates and aborts if invalid.
B.Create a Catalog Client Script with 'onChange' event to validate and show error.
C.Create a UI Policy to set the variable as mandatory and add a condition.
D.Set the variable's 'Type' to 'Integer' and add a 'Min' and 'Max' attribute.
AnswerA

Before Order scripts run on submit and can abort the request with an error message.

Why this answer

Option A is correct because the 'Before Order' script runs server-side when the user clicks the 'Order Now' button, allowing the administrator to validate the 'qty' variable and use `gs.addErrorMessage()` followed by `current.abortAction()` to reject the request with a message. This approach ensures the validation occurs at the point of submission, before the request is processed, and provides immediate feedback to the user.

Exam trap

The trap here is that candidates often confuse client-side validation (like UI Policies or Client Scripts) with server-side enforcement, assuming that showing an error message on the client side is sufficient to reject the request, but only a server-side script like 'Before Order' can truly abort the transaction.

How to eliminate wrong answers

Option B is wrong because a Catalog Client Script with 'onChange' event runs client-side and can show an error message but cannot abort the order submission; it only reacts to field changes, not the final submission. Option C is wrong because a UI Policy can set a variable as mandatory or show/hide fields based on conditions, but it cannot perform custom validation logic like checking a numeric range or aborting the request. Option D is wrong because setting the variable's 'Type' to 'Integer' with 'Min' and 'Max' attributes only enforces the range on the client side for basic input validation, but it does not provide a mechanism to reject the request with a custom message; it simply prevents the user from entering out-of-range values.

Practice this question →
27
MCQhard

A catalog item uses a workflow with a 'Run Script' activity that contains a script to update a custom table. The script works correctly when executed manually in the Scripts Background, but fails when invoked by the workflow. What is the most likely reason?

A.The workflow runs with a different security context, causing permission issues
B.The workflow script references a variable that is undefined in that context
C.The script uses incorrect GlideRecord API methods
D.The workflow is in draft mode
AnswerA

Background scripts run as the user executing them, while workflow scripts may run as system or a designated user with different rights.

Why this answer

The most likely reason is that the workflow runs under the security context of the workflow engine (typically the 'workflow' user or the system user), not the current user's context. When the script is executed manually in Scripts Background, it runs with the full privileges of the admin user, which may include write access to the custom table. In contrast, the workflow's Run Script activity may lack the necessary ACL permissions (e.g., write or create) on the custom table, causing the GlideRecord update to fail silently or throw an error.

Exam trap

ServiceNow often tests the misconception that a script's behavior is identical in all execution contexts, but the trap here is that candidates overlook the security context difference between Scripts Background (admin privileges) and workflow execution (workflow user privileges), leading them to choose a generic scripting error like undefined variables or API misuse.

How to eliminate wrong answers

Option B is wrong because if the script referenced an undefined variable, it would fail in both Scripts Background and the workflow, not just the workflow; the question states the script works manually. Option C is wrong because incorrect GlideRecord API methods would cause failures in both contexts, not selectively; the script works manually, so the API usage is valid. Option D is wrong because a workflow in draft mode cannot be executed at all; the question implies the workflow is running (it fails during execution), so draft mode is irrelevant.

Practice this question →
28
Multi-Selecteasy

A ServiceNow administrator needs to create a service catalog item that requires the user to select a configuration item (CI) that will be affected by the requested service. The catalog item should also send an email notification to the CI's assigned support group when the request is submitted. Which TWO actions must the administrator take?

Select 2 answers
A.Use a variable of type 'CI Selector' to allow selection of a CI.
B.Create a business rule or flow that adds the CI’s assigned support group to the watch list of the CI record upon catalog item submission.
C.Add a variable of type 'Reference' pointing to the Configuration Item [cmdb_ci] table.
D.Set up an email notification on the catalog item itself to send when the request is submitted.
E.Configure the catalog item to automatically populate the 'Assigned group' field on the CI record.
AnswersB, C

Correct: Adding the support group to the watch list enables email notifications to them.

Why this answer

Option B is correct because adding the CI's assigned support group to the watch list of the catalog item (or the request) ensures that the group receives email notifications when the request is submitted. This leverages the platform's notification engine, which sends emails to users and groups in the watch list. Option C is also correct because a Reference variable pointing to the cmdb_ci table allows the user to select a specific CI from the CMDB, which is required for the catalog item to know which CI is affected.

Exam trap

The trap here is that candidates often confuse the 'CI Selector' variable type (which does not exist) with the correct 'Reference' variable type, or they incorrectly think email notifications can be configured directly on a catalog item rather than on the resulting request record.

Practice this question →
29
MCQmedium

An administrator needs to create a workflow that sends an email to the approver when a request is approved, and sends a different email when the request is rejected. What is the appropriate workflow component to use for this branching logic?

A.Use a 'Timer' activity to delay and then check state.
B.Use a 'Begin Approval' activity and then a 'Decision' activity.
C.Use an 'Approval' activity with two 'Outcome' branches.
D.Use a 'Condition' activity to check the approval state.
AnswerC

Approval activity provides outcomes for approved and rejected.

Why this answer

Option C is correct because the 'Approval' activity in ServiceNow workflows inherently supports branching via 'Outcome' branches. When an approval is processed (approved or rejected), the workflow engine evaluates the outcome and follows the corresponding branch, allowing you to attach different email notifications to each path without additional logic activities.

Exam trap

The trap here is that candidates often overcomplicate the solution by adding a separate 'Decision' or 'Condition' activity, not realizing that the 'Approval' activity itself provides native outcome-based branching for approved and rejected states.

How to eliminate wrong answers

Option A is wrong because a 'Timer' activity is used to introduce a delay or schedule a time-based event, not to evaluate approval outcomes or implement branching logic. Option B is wrong because 'Begin Approval' is not a valid workflow activity; the correct activity is 'Approval', and adding a separate 'Decision' activity is redundant since the 'Approval' activity already provides outcome-based branching. Option D is wrong because a 'Condition' activity checks a condition (e.g., field value) but does not directly capture the result of an approval process; using it would require manually setting a state variable, which is less efficient and error-prone compared to the built-in outcome branches of the 'Approval' activity.

Practice this question →
30
MCQeasy

A company wants to collect the same set of user details (name, email, department) in multiple catalog items. What is the best practice to achieve this?

A.Create a single catalog item with all variables and clone it for each item.
B.Create a variable set with the required variables and add it to each catalog item.
C.Use UI policies to display the same fields on multiple items.
D.Configure the variables on the 'sc_cat_item' table and reference them.
AnswerB

Variable sets promote reuse and central management.

Why this answer

Variable sets in ServiceNow allow you to define a reusable group of variables (e.g., name, email, department) that can be added to multiple catalog items. This ensures consistency, reduces duplication, and simplifies maintenance because any update to the variable set automatically propagates to all items that use it. Cloning items (Option A) would create separate copies of the variables, leading to maintenance overhead and potential drift.

Exam trap

The trap here is that candidates confuse UI policies (which control field behavior) with variable sets (which define the fields themselves), leading them to choose Option C because they think 'display the same fields' is a UI policy function, when in fact UI policies cannot create or replicate variable definitions across items.

How to eliminate wrong answers

Option A is wrong because cloning a catalog item creates independent copies of all variables; any future change would need to be applied manually to each clone, defeating the purpose of reuse and increasing administrative burden. Option C is wrong because UI policies control the visibility, readability, or mandatory status of fields on a form, but they do not define or store the variables themselves—they cannot create the same set of fields across multiple items. Option D is wrong because the 'sc_cat_item' table stores catalog item records, not variable definitions; variables are stored in the 'sc_item_option' and related tables, and referencing them directly on the table would not provide a reusable, structured way to add the same fields to multiple items.

Practice this question →
31
MCQhard

A workflow on a catalog item has a 'Set Values' activity that sets the variable 'state' to 'approved'. The workflow then proceeds to a 'Task' activity. However, the task is never created. The log shows the workflow completed successfully. What is a possible reason?

A.The condition on the 'Task' activity evaluated to false
B.The 'Set Values' activity failed silently
C.The catalog item's 'Run workflow' flag is unchecked
D.The workflow is set to run asynchronously and the task is delayed
AnswerA

The Task activity's condition determines whether the task is created. If false, no task is created.

Why this answer

The 'Task' activity in a ServiceNow workflow has a condition property that must evaluate to true for the task to be created. If the condition evaluates to false, the workflow engine skips the activity entirely and continues to the next step, logging the workflow as completed successfully without creating the task. This matches the symptom where the 'Set Values' activity runs (setting state to 'approved') but no task appears.

Exam trap

The trap here is that candidates assume a 'Set Values' activity always leads to the next activity executing, but they overlook that the 'Task' activity itself has a condition that can prevent its execution even when the workflow completes successfully.

How to eliminate wrong answers

Option B is wrong because if the 'Set Values' activity failed silently, the workflow would typically log an error or the state variable would not be set to 'approved', contradicting the given that the workflow completed successfully. Option C is wrong because the 'Run workflow' flag on a catalog item controls whether the workflow triggers at all when the item is requested; if it were unchecked, the workflow would never start, but the log shows it completed. Option D is wrong because asynchronous execution does not prevent task creation; it only means the workflow runs in the background, but the task would still be created once the workflow processes that activity.

Practice this question →
32
MCQhard

A catalog item uses a 'Variable set' that includes several variables. After updating the variable set, the changes do not appear on the catalog item form. What is the most likely cause?

A.The variable set cache has not been cleared
B.The variable set is not published
C.The catalog item's category has been changed
D.The catalog item is shared with a restricted role
AnswerA

ServiceNow caches variable set definitions; clearing the cache or re-saving the catalog item forces an update.

Why this answer

ServiceNow caches variable set definitions to improve performance. When a variable set is updated, the cache must be cleared (via 'Cache Flush' or by deactivating/reactivating the variable set) before the changes are reflected on the catalog item form. Without clearing the cache, the system continues to serve the stale, cached version of the variable set.

Exam trap

The trap here is that candidates assume changes to variable sets are immediately visible, similar to changes to catalog item variables, but ServiceNow's caching mechanism for variable sets requires a manual cache flush to apply updates.

How to eliminate wrong answers

Option B is wrong because variable sets are not 'published' like catalog items or record producers; they are simply active or inactive, and activation alone does not require a publish step. Option C is wrong because changing the catalog item's category does not affect the display of variables from a variable set; categories control item grouping, not variable rendering. Option D is wrong because sharing a catalog item with a restricted role controls visibility and access, not the rendering of variable set changes on the form.

Practice this question →
33
MCQeasy

An order guide contains multiple catalog items. When the order guide is submitted, what is created?

A.One request with one requested item that contains all items
B.Multiple requests, one for each item
C.One request with multiple requested items
D.A single cart item
AnswerC

The order guide bundles items into a single request, each item becomes a requested item.

Why this answer

When an order guide is submitted in ServiceNow, it creates a single request (sc_request) containing multiple requested items (sc_req_item), one for each catalog item in the guide. This is because the order guide acts as a container that groups multiple catalog items into one submission, and the system automatically generates a parent request with child requested items to track fulfillment individually.

Exam trap

The trap here is that candidates often confuse the behavior of an order guide with a record producer or a single catalog item, assuming all items merge into one requested item or that multiple requests are generated, but ServiceNow specifically creates one request with multiple requested items to balance grouping and independent fulfillment.

How to eliminate wrong answers

Option A is wrong because it suggests all items are combined into one requested item, but ServiceNow creates separate requested items for each catalog item to allow independent fulfillment and tracking. Option B is wrong because it implies multiple requests are created, but ServiceNow creates a single request to group the items, not separate requests per item. Option D is wrong because a cart item is a temporary object used during the ordering process, not the final record created upon submission; the submission creates a request and requested items.

Practice this question →
34
MCQmedium

An organization has multiple catalog items that use the same variable set 'Contact Info'. Recently, a change was made to the variable set to add a new variable 'Phone'. However, the existing catalog items that use this variable set do not show the new 'Phone' variable on their forms. The variable set is marked as 'Strictly enforced'? Actually, the variable set is not strictly enforced. The administrator expects the new variable to appear automatically on the items. What should the administrator do?

A.Publish the variable set again from the application publisher.
B.Delete the variable set and recreate it as a new one and re-associate all items.
C.Set the variable set to 'Strictly enforced' to force the new variable to appear.
D.For each catalog item, use the 'Update Variable Set' option to synchronize the changes.
AnswerD

This action updates the item's local copy of the variable set to include the new variable.

Why this answer

Option D is correct because when a variable set is not strictly enforced, changes made to the variable set (such as adding a new variable) are not automatically propagated to catalog items that already use it. The administrator must use the 'Update Variable Set' action on each catalog item to synchronize the item's form with the updated variable set. This action refreshes the item's copy of the variable set variables, making the new 'Phone' variable appear.

Exam trap

The trap here is that candidates assume variable set changes are automatically reflected in all catalog items, but they overlook the distinction between strictly enforced and non-strictly enforced variable sets, where only strictly enforced sets propagate changes automatically.

How to eliminate wrong answers

Option A is wrong because the application publisher is used to publish application scoped updates, not to propagate variable set changes to catalog items; variable sets are not published via the application publisher. Option B is wrong because deleting and recreating the variable set is unnecessarily destructive and time-consuming; the correct approach is to synchronize existing items using the 'Update Variable Set' option. Option C is wrong because setting the variable set to 'Strictly enforced' would force all items to always reflect the latest variable set definition, but the administrator expects the new variable to appear automatically without changing the enforcement mode; the issue is that the items have not been synchronized, not that the variable set is not strictly enforced.

Practice this question →
35
Multi-Selectmedium

Which THREE factors can cause a catalog item to not appear in the service catalog for a user?

Select 3 answers
A.Item has a price
B.User's department is not in the item's entitlement
C.Item's category is not visible to user
D.User does not have the catalog item role
E.Item is inactive
AnswersC, D, E

If the category is not visible (e.g., due to role restrictions), items in that category are hidden.

Why this answer

Option C is correct because the visibility of a catalog item is directly tied to the visibility of its parent category. If a category is not visible to a user (e.g., due to the 'Visible' flag being unchecked or the category being restricted by user criteria), all items within that category will be hidden from the user's service catalog view, regardless of the item's own visibility settings.

Exam trap

ServiceNow often tests the misconception that a price or department field directly controls catalog visibility, when in fact visibility is determined by the category's visibility flag and user criteria, not by pricing or departmental attributes.

Practice this question →
36
MCQeasy

A Service Catalog item has a variable that asks for the user's manager's email. The variable type is 'Email'. When the user submits the item, the manager should receive a notification. How should the variable be configured to ensure the email is valid?

A.Set the variable as 'Read only' and rely on data from sys_user table.
B.Add a regular expression in the variable's 'Regex' field.
C.Use a 'String' variable and add a client script to check format.
D.Use the 'Email' variable type; it includes validation.
AnswerD

The Email type validates the format upon submission.

Why this answer

The 'Email' variable type in Service Catalog automatically validates that the entered value conforms to a standard email format (e.g., user@domain.com). This built-in validation ensures the manager's email is syntactically correct before the notification is triggered, without requiring additional scripting or regex. Option D is correct because it leverages this native validation, which is the simplest and most reliable method.

Exam trap

The trap here is that candidates may overthink the solution and choose a more complex option (like regex or client scripts) instead of recognizing that the platform's native 'Email' variable type already provides the required validation.

How to eliminate wrong answers

Option A is wrong because setting the variable as 'Read only' would prevent the user from entering the manager's email, and relying on data from sys_user table does not guarantee the manager's email is provided or valid for this specific request. Option B is wrong because while a regular expression can validate email format, it is redundant and less maintainable than using the built-in 'Email' type validation, and it does not handle all edge cases (e.g., internationalized email addresses) as robustly. Option C is wrong because using a 'String' variable with a client script to check format is unnecessarily complex, prone to client-side bypass, and duplicates the validation that the 'Email' type already provides natively.

Practice this question →
37
MCQmedium

Refer to the exhibit. A UI policy is defined with the above script condition. Which of the following is correct?

A.The UI policy will only apply if the 'type' field is changed.
B.The UI policy must run on server-side to use g_form.
C.The script is invalid because UI policies cannot use script conditions.
D.The UI policy runs on client-side and makes serial_number mandatory when type is hardware.
AnswerD

UI policies are client-side by default; the script condition is evaluated on the client.

Why this answer

Option D is correct because UI policies run on the client side (in the browser) and can use script conditions to evaluate field values. In this case, the script condition checks if the 'type' field equals 'hardware', and if true, the UI policy makes the 'serial_number' field mandatory. This is a standard client-side behavior for UI policies.

Exam trap

The trap here is that candidates often confuse UI policies (client-side) with business rules (server-side) and incorrectly assume that 'g_form' requires server-side execution, when in fact UI policies are client-side and use 'g_form' natively.

How to eliminate wrong answers

Option A is wrong because UI policies do not require the 'type' field to be changed; they evaluate the condition whenever the form loads or any field changes, depending on the 'onChange' setting, and here the condition is evaluated on form load as well. Option B is wrong because UI policies run on the client side by default, and 'g_form' is a client-side API, not a server-side one; server-side scripts use 'g_scratchpad' or business rules. Option C is wrong because UI policies can indeed use script conditions; the script condition is a valid and common feature of UI policies, allowing complex logic beyond simple field comparisons.

Practice this question →
38
MCQhard

Refer to the exhibit. A ServiceNow administrator configures a catalog item for software installations. The flow logic is as shown. When a user requests 'Adobe Photoshop', the approval goes to Software Approvers instead of IT Management. What is the most likely cause?

A.The variable u_software_name is not being passed to the flow correctly.
B.The condition uses '==' which is case-sensitive; the user typed 'adobe photoshop' in lowercase.
C.The approval group 'IT Management' is not a valid group.
D.The flow is running in an older version that does not support conditions.
AnswerB
Practice this question →
39
MCQmedium

A large enterprise uses ServiceNow for IT service management. The Service Catalog includes a 'New Employee Setup' bundle that contains multiple catalog items such as 'Create AD Account', 'Assign Laptop', and 'Provision Email'. Each catalog item has its own workflow. Recently, the 'Assign Laptop' catalog item has been failing intermittently. The workflow that runs for this item includes an approval step and several tasks. When the workflow fails, the requested item shows a state of 'Work in Progress' and the workflow context shows an error: 'The workflow could not find the activity named: Approve Laptop'. The workflow has an approval activity named 'Approve Laptop' and it is active. The approval activity is set to 'Run as' the workflow user. The workflow is associated with the catalog item correctly. The failure occurs only when the request is submitted by users who are not in the 'IT' role. What is the most likely cause of the failure?

A.The 'Approve Laptop' approval activity is deactivated.
B.The catalog item is not correctly linked to the workflow.
C.The approval activity requires a specific approval group that is not defined.
D.The workflow user does not have sufficient rights to execute the approval activity when the requester lacks the 'IT' role.
AnswerD

Correct: The workflow runs under the context of the workflow user, and if that user cannot access the activity due to ACLs, the workflow fails.

Why this answer

The error 'The workflow could not find the activity named: Approve Laptop' indicates that the workflow engine cannot locate the approval activity at runtime. Since the approval activity is set to 'Run as' the workflow user, and the failure occurs only when the requester lacks the 'IT' role, the most likely cause is that the workflow user does not have sufficient rights (e.g., missing the 'approver' role or ACL permissions) to execute the approval activity when the requester's role triggers a security context restriction. This is a common permission issue in ServiceNow workflows where the execution context of the activity depends on the requester's roles.

Exam trap

The trap here is that candidates assume the error 'could not find the activity' always means the activity is deactivated or missing, but ServiceNow can also throw this error when the activity exists but the execution context (user permissions) prevents the engine from accessing it, especially with 'Run as' settings and role-based restrictions.

How to eliminate wrong answers

Option A is wrong because the question explicitly states the approval activity named 'Approve Laptop' is active, so deactivation is not the issue. Option B is wrong because the workflow is correctly associated with the catalog item (the error is about a missing activity, not a missing workflow link), and the workflow runs partially (shows 'Work in Progress'). Option C is wrong because the error message specifically says 'could not find the activity', not that an approval group is missing; a missing approval group would cause a different error (e.g., 'No approvers available') or the activity would still be found.

Practice this question →
40
MCQeasy

A company wants to allow users to request software licenses through the service catalog. The request requires approval from the manager and then automatically creates a task for the procurement team. Which configuration option should be used?

A.Record Producer
B.Order Guide
C.Variable Set
D.Catalog Item with Approval and Task
AnswerD

A catalog item can be configured with an approval process and a task template to create a task automatically.

Why this answer

Option D is correct because a Catalog Item can be configured with an approval flow (manager approval) and a task creation step for the procurement team, directly fulfilling the requirement. Record Producers create records from catalog requests but lack built-in approval and task generation. Order Guides bundle items but don't handle approvals or tasks.

Variable Sets collect data but don't define workflow actions.

Exam trap

The trap here is that candidates confuse Record Producers with Catalog Items, assuming Record Producers can handle approvals and tasks, but Record Producers are strictly for record creation without workflow automation.

How to eliminate wrong answers

Option A is wrong because a Record Producer is designed to create records (e.g., incidents or change requests) from a catalog request, not to manage approvals or generate tasks for procurement. Option B is wrong because an Order Guide is used to group multiple catalog items into a single order, but it does not provide approval workflows or task creation. Option C is wrong because a Variable Set is a reusable collection of variables for gathering user input, but it has no inherent approval or task generation capabilities.

Practice this question →
41
MCQeasy

A user complains that when they submit a catalog item, they receive an error: 'The variable is mandatory but has no value.' However, the variable is not marked as mandatory in the item's variable definition. What could be the cause?

A.A Catalog Client Script of type 'onSubmit' sets the variable mandatory.
B.A Business Rule on the request table sets the variable mandatory.
C.A UI Policy on the record producer makes the variable mandatory.
D.The variable is mandatory in the parent catalog category.
AnswerA

Client scripts can enforce mandatory before submission.

Why this answer

Option A is correct because a Catalog Client Script of type 'onSubmit' can dynamically set a variable as mandatory using the `g_form.setMandatory('variable_name', true)` method. This overrides the variable's definition in the catalog item, causing the 'mandatory but has no value' error even when the variable is not marked mandatory in the item's variable definition.

Exam trap

The trap here is that candidates assume mandatory status is only set in the variable definition or via UI Policies, overlooking that Catalog Client Scripts of type 'onSubmit' can dynamically enforce mandatory validation at submission time.

How to eliminate wrong answers

Option B is wrong because a Business Rule on the request table operates on the request record after submission, not on the catalog item's variables during submission; it cannot make a variable mandatory at the time of submission to trigger this specific error. Option C is wrong because a UI Policy on the record producer runs on the client side but only changes visibility, read-only state, or mandatory status based on conditions; however, UI Policies do not execute during the onSubmit event of a catalog item—they apply to record producers, not standard catalog items. Option D is wrong because the parent catalog category does not enforce mandatory settings on child catalog items; variable mandatory settings are defined per item, not inherited from the category.

Practice this question →
42
MCQmedium

A catalog item is configured to use an order guide. When a user submits the order guide, only the first catalog item in the guide appears. What is the most likely cause?

A.The workflow attached to the order guide is incomplete
B.The order guide's 'Delivery method' is set to 'One at a time'
C.The catalog items have mandatory variables that are not filled
D.The order guide is in a restricted category
AnswerB

This setting causes items to be presented sequentially, so only the first item appears initially.

Why this answer

Option B is correct because when an order guide's 'Delivery method' is set to 'One at a time', the system processes only the first catalog item and stops, rather than adding all items to the cart. This setting is designed for scenarios where each item must be ordered individually, so submitting the guide results in only the first item appearing.

Exam trap

The trap here is that candidates often confuse 'Delivery method' with fulfillment or delivery scheduling, assuming it controls how items are shipped rather than how they are added to the cart during order guide submission.

How to eliminate wrong answers

Option A is wrong because an incomplete workflow attached to the order guide would affect fulfillment or approval processes, not the initial display of catalog items in the cart after submission. Option C is wrong because mandatory variables that are not filled would typically prevent submission or show validation errors, not cause only the first item to appear. Option D is wrong because a restricted category would prevent the user from seeing or accessing the order guide entirely, not cause partial item display after submission.

Practice this question →
43
MCQmedium

A record producer is configured to use table 'incident' and has a mapping that sets the short description from a variable. When the record producer is submitted, no incident is created. Which is the most likely cause?

A.The user does not have rights to create incidents
B.The table does not have a mandatory field that is not mapped
C.The variable mapping uses a wrong syntax
D.The record producer is not active
AnswerB

Mandatory fields must be mapped or have default values, otherwise record creation fails.

Why this answer

The most likely cause is that the target table (incident) has a mandatory field that is not mapped in the record producer's mapping. When a record producer creates a record, it must satisfy all mandatory field requirements of the target table; if a mandatory field is missing or unmapped, the system will fail to create the record, often without an explicit error to the user.

Exam trap

ServiceNow often tests the concept that a record producer can fail silently due to unmapped mandatory fields, leading candidates to incorrectly suspect permissions or syntax errors instead.

How to eliminate wrong answers

Option A is wrong because if the user lacked rights to create incidents, the system would typically show an ACL error or permission denied message, not silently fail to create the record. Option C is wrong because incorrect variable mapping syntax would usually cause a mapping error or a blank field, but the record producer would still attempt to create the record and might succeed if no mandatory fields are missing. Option D is wrong because if the record producer were inactive, it would not appear to the user at all, or the user would receive a 'producer not found' message, not a silent failure after submission.

Practice this question →
44
MCQeasy

A catalog item has a variable 'Country' and another 'State'. The State variable should be mandatory only when Country is 'USA'. What is the most efficient way to achieve this?

A.Catalog UI policy with condition on Country
B.Workflow with a 'Set Mandatory' activity
C.Variable set with mandatory condition
D.Catalog client script on Country's onChange event
AnswerA

UI Policy actions include setting mandatory based on conditions, which is clean and efficient.

Why this answer

Option B is correct because a Catalog UI Policy can set the mandatory attribute based on a condition. Option A (Client Script) is possible but UI Policy is simpler and more supportable. Option C (Workflow) is for post-submission.

Option D (Variable Set) cannot enforce mandatory conditions.

Practice this question →
45
MCQhard

A large enterprise with over 15,000 users reporting to ServiceNow has a catalog item 'Request New Laptop' that is popular. Recently, users have complained that the form takes a long time to load in the Service Portal. The administrator notices that the catalog item has 20 variables, 3 variable sets, and 5 catalog client scripts. Performance metrics show that the 'sc_cat_item' view is slow. Additionally, the 'Before Order' script contains a loop that queries the user's previous requests. Which corrective action should the administrator take to improve performance?

A.Enable 'Caching' for the catalog item in the 'sys_properties' table.
B.Move the heavy script from the 'Before Order' script to a workflow 'Run Script' activity and simplify client scripts.
C.Increase the number of Service Portal widgets to distribute the load.
D.Remove all variable sets and create individual variables to reduce complexity.
AnswerB

Moving server-side logic from client-triggered scripts to workflows reduces form load time and improves user experience.

Why this answer

Option C is correct: moving the heavy script to a workflow reduces client-side load and improves form rendering. Option A is wrong because increasing the number of widgets may introduce further complexity and is not a performance fix. Option B is wrong because the issue is not related to user roles.

Option D is wrong because while caching can help, the primary performance issue is the synchronous script execution before order.

Practice this question →
46
MCQmedium

A catalog item has a variable of type 'Single Line Text' with a default value. Users report that when they submit the request, the default value is not being used. A catalog client script that runs on submit is setting the variable to empty string. What is the most likely cause?

A.Variable is mandatory
B.Client script runs before default value is applied
C.Client script runs after submit cancels default
D.Default value is only for display, not submission
AnswerB

On submit, client scripts execute before the default value is set to the variable, so the script can override the default.

Why this answer

Option B is correct because catalog client scripts that run on the 'onSubmit' event execute after the default value has been applied to the variable. However, if the client script explicitly sets the variable to an empty string, it overrides the default value before the record is submitted. The default value is applied when the variable is first loaded, but the client script runs during the submission process, effectively clearing it.

Exam trap

The trap here is that candidates may think the default value is applied at submission time or that client scripts run after the default is finalized, but in reality, the default is applied on form load and can be overwritten by an onSubmit client script before the record is saved.

How to eliminate wrong answers

Option A is wrong because making a variable mandatory does not cause the default value to be ignored; mandatory only enforces that a value must be provided, and a default value would satisfy that requirement. Option C is wrong because client scripts that run 'onSubmit' execute before the record is saved, not after submit cancels the default; the default is already applied when the form loads, and the script overrides it during submission. Option D is wrong because default values for 'Single Line Text' variables are not just for display; they are submitted with the request unless explicitly overridden by a client script or other logic.

Practice this question →
47
Multi-Selectmedium

A ServiceNow administrator is configuring a catalog item that requires end users to provide their department and cost center. The administrator wants the 'Cost Center' variable to appear only when the 'Department' variable is set to 'Finance'. Which TWO configurations would enable this behavior?

Select 2 answers
A.Set the 'Cost Center' variable Order field to a value higher than the 'Department' variable.
B.Create a Variable visibility condition on the 'Cost Center' variable that checks when 'Department' equals 'Finance'.
C.Set the 'Cost Center' variable Default value to 'Finance'.
D.Set the 'Cost Center' variable Read only field to true.
E.Set the 'Cost Center' variable Mandatory field to true.
AnswersA, B

The Order field does not control visibility based on another variable's value; it only determines sequence on the form.

Why this answer

Option A is correct because the 'Order' field determines the sequence in which variables appear on a catalog item form. By setting the 'Cost Center' variable's Order value higher than the 'Department' variable's Order value, the 'Cost Center' field will appear after the 'Department' field. This ensures the user selects a department before seeing the cost center, which is necessary for the visibility condition to work correctly.

Option B is correct because a variable visibility condition directly controls when a variable is shown or hidden based on a specified condition, such as 'Department equals Finance'.

Exam trap

The trap here is that candidates often confuse the 'Order' field with visibility control, thinking it alone can show or hide a variable, when in fact it only controls the sequence of fields on the form.

Practice this question →
48
MCQmedium

A workflow includes an 'Approval' activity that requires approval from the user's manager. However, the approval is not being assigned to the manager. What should be checked first?

A.The user's delegation settings in the user profile
B.The workflow stage before the approval activity
C.The 'Approver' field in the approval activity properties
D.The conditions on the approval activity
AnswerC

This field defines the source of the approver; it should be set to a dynamic value like 'Manager'.

Why this answer

The 'Approver' field in the approval activity properties defines who receives the approval request. If it is not set to the user's manager (e.g., using the 'Manager' field from the sys_user table or a reference to the user's manager), the approval will not route correctly. This is the most direct and likely cause, so it should be checked first before investigating other potential issues.

Exam trap

The trap here is that candidates often jump to checking conditions or delegation settings first, overlooking the most fundamental cause—the 'Approver' field being misconfigured or empty—because they assume the manager relationship is automatically resolved.

How to eliminate wrong answers

Option A is wrong because delegation settings control temporary reassignment of approvals for a specific user, not the default routing to a manager; checking delegation is a secondary step after verifying the approver configuration. Option B is wrong because the workflow stage before the approval activity does not determine who receives the approval; it only affects the flow logic (e.g., conditions or transitions) leading to the activity. Option D is wrong because conditions on the approval activity control whether the activity runs at all, not who the approver is; if the activity runs but the approver is missing, conditions are not the root cause.

Practice this question →
49
MCQmedium

A company has a catalog item that includes a variable set for employee information. The variable set has a variable 'Department' that should default to the user's department from their sys_user record. However, the default value is not being applied when a user orders the item. Which of the following is the most likely cause?

A.The 'Default Value' field on the variable set is blank or contains incorrect script.
B.The variable set is configured to 'Display to' only certain roles.
C.The variable is of type 'Reference' instead of 'String'.
D.The user's department is not populated in their user profile.
AnswerA

The default value must be set via script to populate from the user record.

Why this answer

The 'Default Value' field on the variable set is the correct place to define a default value for a variable. If it is blank or contains incorrect script, the system will not populate the 'Department' variable with the user's department from the sys_user record. This directly explains why the default is not being applied.

Exam trap

The trap here is that candidates often confuse the 'Default Value' field with other configuration options like 'Display to' roles or variable type, assuming that a missing user profile field would prevent the default from being applied, when in fact the default script runs regardless of whether the user's department is populated.

How to eliminate wrong answers

Option B is wrong because the 'Display to' roles setting controls visibility of the variable set, not the default value logic. Option C is wrong because the variable type (Reference vs. String) does not affect whether a default value is applied; both types support default values.

Option D is wrong because even if the user's department is not populated, the default value script would still execute and could return null, but the question states the default is not being applied at all, which points to a configuration issue in the 'Default Value' field, not a data issue.

Practice this question →
50
MCQeasy

A small business uses ServiceNow for internal services. The catalog item 'New Employee Onboarding' includes a variable set with a variable 'Start Date'. The workflow sends an email notification to HR when the start date is within 7 days of submission. Currently, the notification is sent immediately upon request submission even if the start date is months away. The workflow has a 'Send Event' activity that triggers a notification. How should the administrator fix this?

A.Add a condition on the 'Send Event' activity to only proceed if the 'Start Date' variable is within 7 days of now.
B.Modify the notification record to include a condition on the 'Start Date' field.
C.Add a 'Mandatory Condition' on the 'Start Date' variable to require it to be within 7 days.
D.Create a business rule on the 'sc_req_item' table that checks the start date and sends the notification.
AnswerA

This ensures the notification is only sent when the condition is met.

Why this answer

Option A is correct because the 'Send Event' activity in a workflow can have a condition that evaluates the 'Start Date' variable against the current date and time. By adding a condition that checks if the start date is within 7 days of now, the workflow will only proceed to send the event (and trigger the notification) when the condition is met, preventing premature notifications.

Exam trap

The trap here is that candidates often confuse the notification record's condition with the workflow activity's condition, or they incorrectly assume that a mandatory condition on the variable can control notification timing, when in fact the workflow's 'Send Event' activity is the correct place to add a time-based condition.

How to eliminate wrong answers

Option B is wrong because modifying the notification record's condition would not affect the workflow's 'Send Event' activity; the notification is triggered by the event, and the condition on the notification record would only filter which events trigger the notification, but the event is still sent immediately. Option C is wrong because a 'Mandatory Condition' on a variable only enforces that the variable must meet the condition at submission time, which would incorrectly block the catalog item from being submitted if the start date is more than 7 days away, rather than controlling the notification timing. Option D is wrong because creating a business rule on the 'sc_req_item' table would run on the server side after the request item is created, but it would not integrate with the workflow's 'Send Event' activity and would require additional logic to send the notification, which is less efficient and not the standard approach for workflow-driven notifications.

Practice this question →
51
MCQeasy

A catalog item has a variable 'Department' and another 'Cost Center'. The Cost Center should only be visible when Department is 'IT'. Which configuration is most efficient?

A.Workflow stage that sets visibility after submission
B.Catalog client script on the Cost Center variable's onChange event
C.Catalog UI policy with a condition on Department
D.Variable set with a condition on Department
AnswerC

UI Policy directly controls visibility based on conditions and is the standard approach.

Why this answer

Option C is correct because a Catalog UI Policy can conditionally show or hide variables on a catalog item based on the value of another variable (e.g., Department = 'IT') without requiring a record to exist or a submission to occur. It runs client-side in real-time as the user fills out the form, making it the most efficient and immediate approach for controlling visibility based on a field value.

Exam trap

The trap here is that candidates often confuse Catalog Client Scripts (which run on variable events) with Catalog UI Policies (which run on conditions), leading them to choose an onChange script that cannot react to changes in a different variable.

How to eliminate wrong answers

Option A is wrong because a workflow stage that sets visibility after submission would only apply the visibility change after the request is submitted, which is too late for the user to see or interact with the Cost Center variable during the ordering process. Option B is wrong because a catalog client script on the Cost Center variable's onChange event would only fire when the Cost Center itself changes, not when the Department changes, so it cannot dynamically show/hide the Cost Center based on Department selection. Option D is wrong because a variable set with a condition on Department would apply the condition to the entire set, not to an individual variable, and it would not allow granular control over a single variable's visibility within the set.

Practice this question →
52
Multi-Selectmedium

Which THREE of the following are true about Service Catalog variables? (Choose three.)

Select 3 answers
A.All catalog variables are stored in the 'sys_variable' table.
B.Once created, the order of variables cannot be changed.
C.Variables can have default values that reference other variables.
D.The variable type determines how the variable is displayed on the form.
E.Variables can be reordered using the 'Order' field in the variable list.
AnswersC, D, E

Default values can be scripted to reference other variables.

Why this answer

Option C is correct because Service Catalog variables can have default values that reference other variables using syntax like '${variable_name}'. This allows dynamic default values based on user input or system data, which is a key feature for creating adaptive catalog forms.

Exam trap

ServiceNow often tests the distinction between variable definition tables (sys_variable) and variable value storage tables (sys_variable_value), and the misconception that variable order is immutable once set.

Practice this question →
53
MCQmedium

A company wants to ensure that when a user submits a catalog item for a new laptop, the request is automatically approved if the cost is under $1,000 and the user's department has sufficient budget. What is the best way to implement this requirement?

A.Configure a notification to inform the user of the approval status.
B.Set up a Business Rule to approve all requests under $1,000.
C.Use a Flow to send an approval request to the manager every time.
D.Create an Approval rule with conditions on cost and department budget.
AnswerD

Approval rules can auto-approve based on conditions.

Why this answer

Option D is correct because Approval rules in ServiceNow are specifically designed to automate approval decisions based on conditions like cost and department budget. By creating an Approval rule on the catalog item, you can evaluate the requested cost against a threshold and check the department's budget balance via a condition script or reference to the budget table, enabling automatic approval without manual intervention.

Exam trap

The trap here is that candidates confuse Business Rules (which run on database operations) with Approval rules (which are part of the approval engine), leading them to choose Option B despite Business Rules not being able to trigger automatic approval decisions in the approval workflow.

How to eliminate wrong answers

Option A is wrong because a notification only informs users of status; it does not perform any approval logic or automatic approval. Option B is wrong because a Business Rule runs on the server side but is not designed for approval workflows; it could set a field but cannot trigger the approval engine's automatic approval action. Option C is wrong because using a Flow to send an approval request to the manager every time defeats the requirement for automatic approval; it always requires manual manager action rather than checking conditions for auto-approval.

Practice this question →
54
MCQmedium

Refer to the exhibit. A user selects 'Full Tunnel' and sees the info message, but the request is auto-approved. What is the most likely cause?

A.The client script runs on load and overrides the workflow condition.
B.The workflow condition is evaluated before the user selects the variable value.
C.The workflow condition is based on the variable 'u_vpn_type' but the condition is incorrectly configured to use '==' instead of '==='.
D.The workflow condition uses the variable value from the request, which may be set to 'Split Tunnel' due to a default.
Practice this question →
55
MCQhard

A catalog client script is used to populate a variable's value from an external table. The script works in the development instance but fails in production. Which troubleshooting step should be taken first?

A.Ensure the external table exists in the production instance
B.Review the system logs for script errors
C.Verify that the script's 'Run as' and 'Global' flags are set correctly in production
D.Check if the workflow attached to the catalog item is active
AnswerC

Client scripts may depend on user context; production might have different security or scope settings.

Why this answer

Option A is correct because catalog client scripts can be context-sensitive; checking the script's 'Run as' or 'Global' setting reveals scope differences. Option B (workflow) is irrelevant. Option C (log) is possible but not first step.

Option D (table) does not address client script execution context.

Practice this question →
56
MCQmedium

A user reports that a catalog item's 'Requested for' field is not being set correctly after submission. The catalog item uses a workflow that includes a 'Set Requested For' activity. What is the most likely cause?

A.The workflow context variable for requested for is missing
B.The workflow is not published
C.The 'Set Requested For' activity is configured with a static user value
D.The catalog item variable mapping is incorrectly configured
AnswerC

This activity can explicitly set the requested for user; if static, it replaces the submitted value.

Why this answer

The 'Set Requested For' activity in a ServiceNow workflow explicitly overrides the 'Requested for' field on the catalog item. If it is configured with a static user value, it will always set that user regardless of who submitted the request, causing the reported issue. This is the most direct cause because the activity's configuration takes precedence over the default behavior of populating the field with the requester.

Exam trap

The trap here is that candidates often assume the issue is with variable mapping or workflow publishing, when in fact the 'Set Requested For' activity's static configuration directly overrides the expected dynamic behavior.

How to eliminate wrong answers

Option A is wrong because the workflow context variable for 'requested for' is not a standard variable; the 'Set Requested For' activity uses its own configuration, not a context variable. Option B is wrong because an unpublished workflow would prevent the catalog item from functioning entirely, not just cause a specific field to be set incorrectly. Option D is wrong because catalog item variable mappings control how variables are passed to the workflow, not the 'Requested for' field, which is a system field handled separately by the 'Set Requested For' activity.

Practice this question →
57
MCQhard

A catalog item is configured but does not appear in the Service Portal for end users. The item is categorized under 'Software' and the catalog is 'IT Services'. The Service Portal widget 'sc_category_item' is used. Which of the following is the most likely reason?

A.The catalog item's 'Order' field is set to 0.
B.The catalog item's 'Portal' field is empty or set to the wrong portal.
C.The catalog item has a 'Roles' restriction that does not include the user's role.
D.The catalog item's 'Module' is not set to 'Service Catalog'.
AnswerB

The Portal field must be set to the correct portal for the item to appear there.

Why this answer

The most likely reason is that the catalog item's 'Portal' field is empty or set to the wrong portal. In ServiceNow, the 'Portal' field on a catalog item determines which Service Portal(s) the item appears in. If this field does not include the target portal (e.g., 'IT Services'), the item will not be visible in that portal's catalog, even if the 'sc_category_item' widget is used.

This is a common configuration oversight.

Exam trap

The trap here is that candidates often confuse the 'Portal' field with the 'Category' or 'Roles' fields, assuming that if the item is in the correct category and no roles are set, it should appear everywhere, but the Portal field explicitly scopes visibility to specific portals.

How to eliminate wrong answers

Option A is wrong because setting the 'Order' field to 0 does not hide the item; it simply places it at the top of the list (lowest order value) or may cause it to appear first, not disappear. Option C is wrong because a 'Roles' restriction would prevent the item from being visible to users without that role, but the question states the item is not visible to end users at all, not that it is visible to some but not others; the 'Portal' field is a more direct cause for complete invisibility. Option D is wrong because the 'Module' field is not a standard field on a catalog item; it is used on record producers or other configurations, and the Service Catalog module is automatically associated with catalog items via the 'sc_cat_item' table, so this is not a relevant setting.

Practice this question →
58
MCQmedium

Refer to the exhibit. When a user submits a request for a laptop, the approval is granted by admin even though admin is not the manager. Which configuration allows this?

A.Admin has the 'approval_admin' role that overrides normal approval constraints.
B.The workflow has an approval activity with 'Delegate to group' and admin is the group manager.
C.The catalog item's approval rule is set to 'Use approval group' and admin is a member of that group.
D.The approval group 'IT Hardware' has admin as a member and approval delegation is enabled.
AnswerC
Practice this question →
59
Drag & Dropmedium

Drag and drop the steps to create a new Business Rule in ServiceNow into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order

Why this order

Business Rules run on server-side when records are inserted, updated, or deleted.

Practice this question →
60
Multi-Selectmedium

Which TWO of the following are true regarding catalog item variables? (Choose two.)

Select 2 answers
A.Variables defined on a catalog item cannot be referenced in workflows.
B.Variables are always displayed in the order they were created.
C.Variables can be configured as 'Read only' after submission.
D.Variables in a variable set are independent and cannot share values across sets.
E.Variables can have a 'Default Value' that is populated by a script.
AnswersC, E

Read only setting controls editability on the request form after submit.

Why this answer

Options B and D are correct. Option A is wrong because variables can be referenced in workflows via 'current.variables.variable_name'. Option C is wrong because variable sets can be shared, but the variables themselves are independent if cloned.

Option E is wrong because variables can be ordered by 'Order' field.

Practice this question →
61
MCQmedium

Refer to the exhibit. A workflow for a catalog item has three stages. The 'Run Script' activity sets the assigned_to to the current user (the requester). The approval activity approves by the manager. The 'Create Task' activity creates a catalog task. When the workflow runs, the task is created but is assigned to the requester instead of the fulfillment group. What is the likely cause?

A.The task creation activity is configured to assign to the requester by default.
B.The 'Run Script' activity sets the assigned_to on the request, but the task creation activity does not copy that value; the task should have its own assignment.
C.The workflow should have a 'Set Values' activity after the approval to assign the task.
D.The approval activity reassigned the request to the manager.
AnswerB

The script modifies the request record, not the task.

Why this answer

Option B is correct because the 'Run Script' activity sets the `assigned_to` field on the request record itself, but the 'Create Task' activity creates a separate catalog task record. The task creation activity does not automatically inherit the `assigned_to` value from the request; it uses its own assignment configuration, which defaults to the requester if no fulfillment group or specific assignment is defined. This causes the task to be assigned to the requester instead of the intended fulfillment group.

Exam trap

ServiceNow often tests the misconception that setting a field on the request record (via a 'Run Script' activity) will automatically propagate to child records like tasks, when in reality each record type has its own independent assignment logic.

How to eliminate wrong answers

Option A is wrong because the task creation activity does not have a default to assign to the requester; the assignment behavior depends on the activity's configuration, such as the 'Assignment group' or 'Assigned to' fields, which are not set to the requester by default. Option C is wrong because a 'Set Values' activity after approval would not fix the issue; the assignment must be configured within the 'Create Task' activity itself or via a script that explicitly sets the task's assignment fields. Option D is wrong because the approval activity approves by the manager but does not reassign the request; it only changes the state of the approval record, not the `assigned_to` field of the request or task.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Service Catalog Workflows questions.

Start 20-question session