Buttons, form links, and context menu items are all examples of what type of functionality?
B
Explanation:
In ServiceNow, UI Actions are used to add buttons, links, and context menu items to forms and lists,
enabling users to perform specific actions easily. UI Actions are essential for customizing the user
experience and streamlining workflow interactions.
Understanding UI Actions in ServiceNow:
UI Actions allow administrators to create interactive elements such as:
Buttons (e.g., "Save," "Approve," "Reject")
Form Links (Clickable links that trigger actions on a record)
Context Menu Items (Right-click menu options for records in lists and forms)
They can execute client-side (via JavaScript) or server-side (via scripts or GlideRecord API calls).
UI Actions enhance usability by allowing quick execution of tasks without navigating through
multiple screens.
Why is Option B (UI Action) Correct?
✅
Buttons, form links, and context menu items are all created and managed using UI Actions in
ServiceNow.
UI Actions define what happens when a button or menu item is clicked, including executing scripts,
navigating to a different page, or performing an operation on a record.
Why Are the Other Options Incorrect?
❌
A. Business Rule
Business Rules run automatically on the server-side when records are inserted, updated, deleted, or
queried.
They do not create buttons, links, or context menu items on the UI.
❌
C. Client Script
Client Scripts execute on the client-side (browser) and are used for form validation, field changes,
and UI behavior modifications.
They do not create UI elements like buttons or menu items.
❌
D. UI Policy
UI Policies dynamically change form field behavior (e.g., hiding, showing, making fields mandatory,
or read-only).
They do not add buttons or context menu items.
Reference from Certified System Administrator (CSA) Documentation:
ServiceNow Docs – UI Actions Overview
ServiceNow UI Actions Documentation
"UI Actions add buttons, links, and context menu items on forms and lists to enhance user
interaction with the ServiceNow platform."
Which of the following is true of Service Catalog Items in relation to the Service Catalog?
B
Explanation:
In ServiceNow, the Service Catalog is a centralized portal where users can request IT services,
hardware, software, and other business-related items. Within the Service Catalog, the fundamental
components are known as Service Catalog Items.
Understanding Service Catalog Items
Definition of Service Catalog Items:
A Service Catalog Item represents a specific service, product, or action that a user can request from
the Service Catalog.
It is the core component that defines what users can request.
Examples include:
Requesting a new laptop
Submitting an access request
Ordering a software installation
Why They Are the "Building Blocks" of the Service Catalog:
All Service Catalog requests are based on catalog items—without them, the catalog has no offerings.
Each item has associated workflows, approvals, and fulfillment processes that define how the
request is handled.
They form the foundation of the Service Catalog because every service request must be tied to an
item.
Why Answer "B" is Correct:
️
"They are the building blocks."
✔
Service Catalog Items serve as the fundamental components of the catalog.
They define what services and products are available for request.
Without catalog items, the Service Catalog would not function as intended.
Why the Other Answers Are Incorrect:
❌
A. "They run behind the scenes."
Incorrect because Service Catalog Items are visible to users in the Service Catalog portal.
While workflows and fulfillment processes may operate in the background, the items themselves are
not hidden.
❌
C. "They are optional."
Incorrect because Service Catalog Items are mandatory for a functioning Service Catalog.
The catalog is useless without catalog items, making them essential, not optional.
❌
D. "They provide options."
Incorrect because while Service Catalog Items can have variables (such as dropdown selections or
checkboxes), their primary role is not just to provide options but to define the services available.
Reference from the Certified System Administrator (CSA) Documentation:
ServiceNow CSA Study Guide – Service Catalog & Request Management
ServiceNow Docs: Service Catalog Overview (ServiceNow Documentation)
ServiceNow Tables & Data Model (sc_catalog, sc_cat_item, sc_request, sc_task)
Table Access Control rules are processed in the following order:
B
Explanation:
In ServiceNow, Table Access Control (ACL) rules define the permissions for accessing records within a
table. When a user attempts to access a record, ServiceNow processes ACL rules in a specific order to
determine if the user has the necessary permissions.
Order of Processing ACL Rules:
Specific Table Name ACLs
ServiceNow first checks ACL rules that are defined for the exact table being accessed.
If there are multiple ACL rules for the same table, ServiceNow evaluates them from most specific to
least specific (i.e., field-level ACLs before table-level ACLs).
Parent Table Name ACLs (If applicable)
If the table inherits from another table (e.g., Incident inherits from Task), ServiceNow next checks
ACL rules on the parent table.
This ensures that inherited rules are properly applied.
Wildcard ACLs (*) (Any table)
If no explicit ACL rule is found for the table or its parent, ServiceNow checks wildcard ACL rules (*),
which apply to all tables.
Wildcard ACLs act as a last resort when no table-specific rules exist.
Explanation of Each Option:
(A) any table name (wildcard), parent table name, table name – Incorrect
Wildcard rules (*) are processed last, not first.
(B) table name, parent table name, any table name (wildcard) – Correct
This follows the correct processing order:
First: ACLs for the specific table
Second: ACLs for the parent table (if applicable)
Third: Wildcard ACLs (*)
(C) parent table name, table name, any table name (wildcard) – Incorrect
Parent table ACLs are checked after table-specific ACLs, not before.
(D) any table name (wildcard), table name, parent table name – Incorrect
Wildcard ACLs (*) are always processed last, so this order is incorrect.
Additional Notes & Best Practices:
Field-level ACLs (column-specific) take precedence over table-level ACLs.
If multiple ACL rules apply, all must evaluate to true for access to be granted.
Explicit Deny: If an ACL rule explicitly denies access, the user is denied, even if another ACL grants
access.
Always Test ACLs: Use the "Security Debugging" feature (/sys_security_acl_list.do) to verify how ACLs
are applied.
Reference from Certified System Administrator (CSA) Documentation:
ServiceNow Docs: How Access Control Rules Work
https://docs.servicenow.com
ServiceNow Community: Understanding ACL Processing Order
https://community.servicenow.com
What is the platform name for the User table?
D
Explanation:
In ServiceNow, every table has a unique platform name (also known as the database name or sys_id).
The table that stores user records in ServiceNow is called "sys_user".
Understanding the sys_user Table:
Table Name: sys_user
Purpose: Stores user records, including their roles, group memberships, and personal details.
Location in ServiceNow: You can access this table by navigating to:
All → Users and Groups → Users
Key Fields in sys_user Table:
User ID (user_name) – Unique identifier for the user.
Name (name) – Full name of the user.
Email (email) – Email address of the user.
Roles (roles) – Defines user permissions in the system.
Active (active) – Indicates if the user is active in the system.
Explanation of Incorrect Answers:
A . u_users – Incorrect. The prefix u_ is typically used for custom tables created by administrators.
This is not a default system table.
B . sys_users – Incorrect. The correct name is sys_user (singular), not sys_users. ServiceNow follows a
singular naming convention for system tables.
C . x_users – Incorrect. The prefix x_ is reserved for Scoped Applications created within an instance.
The User table is a core system table, not a scoped one.
Reference from Certified System Administrator (CSA) Documentation:
ServiceNow Product Documentation → User Administration → sys_user Table
ServiceNow Tables Reference → sys_user
ServiceNow CSA Study Guide → User and Data Administration
A REQ number in the Service Catalog represents…
A
Explanation:
In the ServiceNow Service Catalog, a REQ number represents a Request (REQ) record, which
functions as an order number for a service request. When a user submits a request through the
Service Catalog, the system generates a Request (REQ) record, which tracks the overall order.
Breakdown of the Service Catalog Request Structure:
REQ (Request Record) – The Order Number
This is the parent record that represents the entire order/request submitted by the user.
It contains key details such as the requester, the total cost, approval status, and the overall request
state.
Example: REQ0010023
RITM (Requested Item) – The Individual Catalog Item
Each item requested within a REQ has its own Requested Item (RITM) record.
The RITM tracks the fulfillment of a specific item within the order.
Example: RITM0010456 (a single laptop ordered in a request)
TASK (Catalog Task) – The Actions to Complete the Request
Catalog Tasks (TASK) are created under an RITM to handle specific fulfillment steps.
Multiple tasks can exist under a single RITM, assigned to different fulfillment teams.
Example: TASK0013456 (a task assigned to IT Support to configure the laptop)
Why the Other Options Are Incorrect:
❌
B. The stage (Incorrect)
The stage of a request is part of the request lifecycle (e.g., Approval, Fulfillment, Completed), but it is
not represented by the REQ number.
❌
C. The task to complete (Incorrect)
A task to complete is represented by a Catalog Task (TASK), not the REQ number.
Tasks are specific actions assigned to fulfill an item request.
❌
D. The individual item in the order (Incorrect)
An individual item in a Service Catalog request is represented by a Requested Item (RITM), not the
REQ number.
Example Scenario:
A user submits a request for a new laptop and a software license:
REQ0012345 → Tracks the overall request (Order Number)
RITM0016789 → Laptop Request
TASK0018901 → IT configures the laptop
RITM0016790 → Software License Request
TASK0018902 → IT assigns the software license
Reference:
ServiceNow Documentation: Request Management Overview
ServiceNow Learning: Service Catalog Fundamentals
ServiceNow Docs: Understanding Requests, RITMs, and Tasks
Which would NOT appear in the History section of the Application Navigator?
B
Explanation:
The History section in the Application Navigator tracks recently visited records, lists, and forms within
ServiceNow. This feature allows users to quickly navigate back to previously accessed content
without searching manually.
What Appears in the History Section?
The History section logs user activity related to:
✅
Records (
Option A) – Recently viewed records from any table, such as incidents, requests, or
tasks.
✅
Lists (
Option C) – Any list views a user has accessed, such as Incident List or Change Request List.
✅
Forms (
Option D) – Any individual record viewed in form view, such as an incident form or user
form.
Why is Option B (UI Pages) Correct?
❌
UI Pages do NOT appear in the History section.
UI Pages are special custom pages built with Jelly scripting and used for custom interfaces, portals,
and dashboards (e.g., Service Portal pages).
Since they do not represent individual records, lists, or forms, they are not included in the user’s
History tracking.
Why Are the Other Options Incorrect?
❌
A. Records
Records are individual database entries (e.g., specific incidents, change requests, or users).
Since records are frequently accessed, they are logged in History.
❌
C. Lists
Lists display multiple records from a table (e.g., all open incidents).
Since users navigate through lists frequently, they are logged in History.
❌
D. Forms
Forms are used to view or edit individual records (e.g., an incident form).
Since forms are commonly accessed, they are logged in History.
Reference from Certified System Administrator (CSA) Documentation:
ServiceNow Docs – Application Navigator & History
ServiceNow Application Navigator Documentation
"The History section of the Application Navigator displays a list of the records, lists, and forms that
you have recently accessed."
"Custom UI Pages are not included in History tracking."
Which one of the following statements is a recommendation from ServiceNow about Update Sets?
A
Explanation:
Update Sets in ServiceNow are used to capture customizations and configurations made in an
instance, allowing these changes to be moved between instances (e.g., from development to test or
production). ServiceNow provides best practices to ensure smooth migration and avoid issues with
missing or conflicting updates.
Understanding Update Sets in ServiceNow:
What is an Update Set?
An Update Set is a collection of customizations (e.g., changes to forms, scripts, workflows, business
rules) that can be moved from one instance to another.
It tracks changes in a controlled way, preventing accidental loss of configurations.
Why Avoid Using the Default Update Set?
The Default Update Set is automatically used when no other update set is selected.
It captures changes but should never be used for instance-to-instance migrations because:
It cannot be exported.
It contains system changes that are not logically grouped.
It can cause inconsistencies and missing dependencies when moving updates.
Instead, administrators should create a named Update Set for specific development work.
Why Answer "A" is Correct:
️
"Avoid using the Default Update Set as an Update Set for moving customizations from instance
✔
to instance."
This follows ServiceNow’s best practices for managing Update Sets.
Using the Default Update Set can lead to missing updates, conflicts, and untracked changes, making
migrations unreliable.
Why the Other Answers Are Incorrect:
❌
B. "Before moving customizations from instance to instance with Update Sets, ensure that both
instances are different versions."
Incorrect because ServiceNow recommends that instances be on the same version before applying
Update Sets.
If instances are on different versions, the Update Set may include incompatible changes, causing
failures.
❌
C. "Use the Baseline Update Set to store the contents of items after they are changed the first
time."
Incorrect because there is no such thing as a "Baseline Update Set" in ServiceNow.
ServiceNow does not automatically create a backup of original configurations—administrators
should manually create an Update Set before making changes.
❌
D. "Once an Update Set is closed as 'Complete,' change it back to 'In Progress' until it is applied to
another instance."
Incorrect because a completed Update Set should not be reopened.
Once marked Complete, an Update Set is ready for export and migration. Reopening it can cause
data integrity issues and confusion in version control.
Reference from the Certified System Administrator (CSA) Documentation:
ServiceNow CSA Study Guide – Update Sets & Configuration Management
ServiceNow Docs: Best Practices for Update Sets (ServiceNow Documentation)
ServiceNow Docs: Moving Customizations with Update Sets
Which of the following is used to initiate a flow?
A
Explanation:
In ServiceNow Flow Designer, a Trigger is used to initiate a flow. Triggers define the conditions under
which a flow starts and can be based on various system events, schedules, or user actions.
Explanation of Each Option:
✅
(A) A Trigger – Correct
Triggers are the starting point of a flow in Flow Designer.
A flow will not execute unless a trigger condition is met.
Types of triggers include:
Record-based triggers (e.g., when a record is created, updated, or deleted)
Scheduled triggers (e.g., run at a specific time or interval)
Application-specific triggers (e.g., Service Catalog request submission)
❌
(B) Core Action – Incorrect
Core Actions are predefined actions that execute tasks within a flow, such as:
Sending notifications
Updating records
Calling APIs
They are steps within a flow, not what initiates it.
❌
(C) A Spoke – Incorrect
A spoke in Flow Designer is a collection of actions and subflows related to a specific application or
integration (e.g., ServiceNow ITSM Spoke).
Spokes contain actions but do not initiate flows.
❌
(D) An Event – Incorrect
Events in ServiceNow trigger Business Rules, Notifications, and Script Actions, but they are not
directly used to initiate flows in Flow Designer.
However, a flow can be triggered based on an event, but the event itself is not the trigger—the
flow’s trigger is configured to listen for the event.
Additional Notes & Best Practices:
Triggers should be well-defined to prevent unnecessary flow executions that might impact
performance.
Use Scheduled Triggers for time-based workflows (e.g., daily reports).
Record Triggers are commonly used for automation within ITSM processes.
Debugging Triggers: Use the Flow Execution Details page to troubleshoot trigger execution.
Reference from Certified System Administrator (CSA) Documentation:
ServiceNow Docs: Flow Designer Triggers
https://docs.servicenow.com
ServiceNow Community: Best Practices for Flow Designer Triggers
https://community.servicenow.com
For Administrators creating new Service Catalog items, what is a characteristic they should know
about Service Catalog variables?
D
Explanation:
Service Catalog variables in ServiceNow are used to capture user input when they request catalog
items, record producers, or order guides. These variables help customize user interactions and drive
automation within Service Catalog workflows.
Key Characteristics of Service Catalog Variables:
Global by Default:
When a Service Catalog variable is created, it is global by default, meaning it can be used across
multiple catalog items unless scoped to a specific item.
This helps in reusability of variables across different catalog items, reducing redundancy.
However, administrators can disable the "Global" checkbox if they want the variable to be specific to
one catalog item.
Types of Service Catalog Variables:
Variables can be single-line text, choice lists, reference fields, checkbox, multi-line text, and more.
They allow administrators to collect structured data from users during item requests.
Reusability Across Catalog Items:
Global variables can be used across multiple catalog items without creating duplicate variables.
This is useful when multiple items require the same type of user input (e.g., location, department).
Visibility and Dependency:
ServiceNow allows UI policies and catalog client scripts to control the behavior of these variables
dynamically.
Admins can configure visibility, mandatory status, or dependencies based on user selections.
Explanation of Other Options (Why They Are Incorrect):
Option A (Service Catalog variables can only be used in Record Producers) – Incorrect
While Service Catalog variables can be used in Record Producers, they are not limited to them.
Variables can also be used in Catalog Items, Order Guides, and Requested Items (RITM).
Option B (Service Catalog variables can only be used in Order Guides) – Incorrect
Service Catalog variables can be used in Order Guides, but they are not restricted to them.
Order Guides allow multiple items to be ordered together, but variables can be used independently
in Catalog Items and Record Producers as well.
Option C (Service Catalog variables cannot affect the order price) – Incorrect
Service Catalog variables can affect pricing through Variable Price Mapping.
If configured, variables (like dropdowns or checkboxes) can be linked to a price adjustment,
impacting the total cost of the request.
For example, selecting "Additional Storage" in a cloud server request could add extra costs
dynamically.
Official Reference from ServiceNow Certified System Administrator (CSA) Documentation:
ServiceNow Documentation – Service Catalog Variables: ServiceNow Variables Guide
ServiceNow CSA Exam Guide: Covers Service Catalog fundamentals, including variable behavior and
reusability.
Which one of the following statements is true about Column Context Menus?
A
Explanation:
Column Context Menus in ServiceNow provide options for interacting with list columns in a table.
These menus allow users to customize list views, generate quick reports, export data, and configure
list settings.
When users right-click on a column header in a list view, they see a context menu with several
actions. The correct answer, Option A, correctly describes these capabilities.
Key Features of Column Context Menus:
Create Quick Reports
Users can generate bar charts, pie charts, or other visual reports based on column data.
Example: Right-clicking on the "State" column in an Incidents list allows users to create a report
showing the count of incidents per state.
Configure the List
Users can modify the list layout, display additional columns, or customize fields.
Options include Personalize List, Show / Hide Columns, and Sort features.
Export Data
Data can be exported in various formats, such as Excel, CSV, PDF, or XML.
Example: Exporting all incidents assigned to a particular group.
Why the Other Options Are Incorrect:
❌
B. It displays actions related to filtering options, assigning tags, and search (Incorrect)
Filtering options are part of the Filter Navigator and List Context Menu, not the Column Context
Menu.
Assigning tags and performing searches happen within the list view but are not primary functions of
the Column Context Menu.
❌
C. It displays actions related to viewing and filtering the entire list (Incorrect)
While column menus allow sorting and filtering, filtering the entire list is mainly done via the List
Context Menu (right-clicking the entire list or using the filter option at the top).
❌
D. It displays actions such as view form, view related task, and add relationship (Incorrect)
Viewing forms, related tasks, and adding relationships are functions available when interacting with
record-level actions (right-clicking a row), not a column.
These actions are available via the List Context Menu or Related Lists, not the Column Context Menu.
Example of Using a Column Context Menu in ServiceNow:
Navigate to Incident > All.
Right-click on the Priority column header.
A menu appears with options such as:
Sort (Ascending/Descending)
Group By This Field
Create Report
Export Data
Configure List Layout
Reference:
ServiceNow Documentation: Working with Lists
ServiceNow Docs: List and Column Context Menus
ServiceNow Learning: List Management and Customization