Free CSA Practice Test

When data is imported into ServiceNow from an external data source, it is not loaded directly into the target table. Instead, the platform first places the raw data into a temporary table that acts as a staging area. This table is technically an "Import Set Row" table, which extends the base sysimportsetrow table. Each import process creates a new table with a unique name (e.g., uimp...) for this purpose. This staging process allows for data to be validated and transformed via a Transform Map before being committed to its final destination table, ensuring data integrity.

A. Transform Table: This is not a standard ServiceNow term. The related component is a "Transform Map," which defines field mappings, not a table.
B. Staging Table: While this is a conceptually correct generic term, "Import Set Row Table" is the more specific and technically accurate name used within the ServiceNow platform.
D. Temp Table: This is a generic database term. ServiceNow uses the specific "Import Set Row Table" terminology for its import staging process.

1. ServiceNow Product Documentation - Import Sets: "The Import Set table acts as a staging area for records imported from a data source." This document clarifies the role of the staging table in the import process. (ServiceNow, Import Sets, Doc ID: KB0719038, Section: "Import Set Process").

2. ServiceNow Product Documentation - Import set tables: "When a new import set is created, the system creates a table to store the imported data... This table is referred to as the import set table or staging table. All import set tables extend the Import Set Row [sysimportsetrow] table." This reference confirms the table's name, purpose, and its extension from the sysimportsetrow base table. (ServiceNow, Import set tables, Doc ID: 1119811).

3. ServiceNow Developer Portal - Import Sets Concepts: "Data is imported into a staging table... A transform map provides a guide for moving data from the staging table to a target table." (ServiceNow Developer Program, Import Sets, Section: "Import Set Concepts").

ServiceNow provides three primary types of Visual Task Boards (VTBs) for managing tasks. These are Guided (also known as Data Driven), Flexible, and Freeform boards. Guided boards automatically generate lanes based on field values (e.g., State). Flexible boards offer a combination of field-driven and freeform lanes. Freeform boards allow users to create custom lanes and manually add any task. "Feature" is not a recognized, standard type of Visual Task Board on the ServiceNow platform.

B. Guided boards: This is a standard VTB type where lanes are automatically created from the values of a specific field, such as 'State' or 'Priority'.
C. Flexible: This is a standard VTB type that combines the features of guided boards with the ability to add additional freeform lanes.
D. Freeform: This is a standard VTB type that allows users to create their own lanes and manually add any task record to them.

1. ServiceNow Product Documentation: Visual Task Boards. In the section "Types of visual task boards," the documentation explicitly lists and describes the three valid types: "Freeform boards," "Data driven boards (Guided boards)," and "Flexible boards." The term "Feature board" is not mentioned as a VTB type.

2. ServiceNow Developer Documentation: Visual Task Boards. This resource also outlines the creation and use of the three core VTB types, reinforcing that Guided, Flexible, and Freeform are the officially supported classifications.

UI Policies are client-side rules used to dynamically change the behavior and visibility of fields on a form without scripting, although scripting can be used for more complex logic. The first requirement—making "Resolution code" mandatory when the "State" is "Resolved"—is a standard condition-based UI Policy. The second requirement—hiding a field unless the user has a specific role—can be achieved using the "Run scripts" option within a UI Policy. The script would use guser.hasRole() to check the user's role and gform.setVisible() to control the field's visibility, making UI Policy the correct tool for both requirements.

A. Dictionary Design: This defines a field's attributes globally (e.g., always mandatory), not conditionally based on form values or user roles.
B. Field Limiter: This is not a standard, recognized term for a type of rule or configuration element within the ServiceNow platform.
D. UI Design: This refers to the general practice of designing a user interface, not a specific type of configurable rule in ServiceNow.
E. Form Constraint: This is not a standard, recognized term for a type of rule or configuration element within the ServiceNow platform. ---

1. ServiceNow Product Documentation: "UI policies". This document states, "UI policies dynamically change the behavior of information on a form... You can use UI policies to set fields on a form to mandatory, visible, or read-only." It also details the use of conditions and scripts for advanced logic. Platform Administration > User interface > UI policies.

2. ServiceNow Developer Site: "Client-Side Scripting" Learning Module, "UI Policies" section. This module explains, "UI Policies can have scripts that execute on the client. Use UI Policy scripts to create complex conditional checks or to take actions other than setting field attributes (mandatory, visible, read-only)." This directly supports using UI Policies for role-based visibility checks.

3. ServiceNow Now Learning: "ServiceNow Fundamentals" Courseware. In the module on "User Interface & Navigation," the section on "Form Configuration" introduces UI Policies as a primary method to control field visibility and mandatory status based on defined conditions.

A filter condition in ServiceNow is a fundamental construct used to query records from a table. Each individual condition, often referred to as a "breadcrumb," is composed of three distinct parts:
1. Field: The specific data element on the table to be evaluated (e.g., 'State', 'Priority').
2. Operator: The logical comparison to be performed (e.g., 'is', 'is not', 'greater than').
3. Value: The data that the field is compared against (e.g., 'New', '1 - Critical'). These three components work together to form a complete logical statement that the system uses to return a specific subset of records.

A. Column: While "Column" is a common database term, ServiceNow's official terminology for this component within the condition builder is "Field."
B. Match Criteria: This is a general term that describes the result of the combined components (Field, Operator, and Value), not a single component itself.

1. ServiceNow Product Documentation: On the "Condition builder" page, it states, "Each filter is made up of three components: a field, an operator, and a value." This is the foundational structure for building queries in lists, reports, and scripts. (ServiceNow. (2024). Condition builder. Now Platform Administration Documentation).

2. ServiceNow Fundamentals (SNF) Participant Guide: The "Now Platform User Interface" module explains the components of list filters. It explicitly breaks down a filter into the Field, Operator, and Value selectors, which are the three parts of a condition. (ServiceNow. (2024). ServiceNow Fundamentals Participant Guide. Now Learning).

The icon composed of three stacked horizontal lines, located in the header of a form or list, is universally known in user interface (UI) design as the "Hamburger icon." In the ServiceNow platform, clicking this icon reveals the "Additional actions menu," also referred to as the form context menu. While the menu has a functional name, the question specifically asks for the name of the icon itself, for which "Hamburger icon" is the correct and most common term.

A. Pancake icon: This is an incorrect term; "pancake icon" sometimes refers to an icon with three stacked dots, not lines.
B. Additional Actions or Context Menu: This describes the menu that appears after clicking the icon, not the name of the icon itself.
D. Cake icon: This is a fabricated and incorrect term for this UI element.

1. ServiceNow Product Documentation - Using the Mobile Agent app: In the section describing the app's navigation, the documentation explicitly states, "Tap the hamburger icon (...) to open the drawer." This confirms official use of the term. (ServiceNow Product Documentation, Tokyo Release, Mobile Apps and Platform > ServiceNow Agent > Using the Mobile Agent app).

2. ServiceNow Product Documentation - Form context menu: This document shows an image of the three-bar icon on the form header and refers to the menu it opens as the "form context menu." This supports the distinction that Option B refers to the menu, not the icon. (ServiceNow Product Documentation, Tokyo Release, Now Platform user interface > UI actions > Form context menu).

The Application Navigator search field, often called the "filter navigator," is a core UI component for locating navigation items. Its search functionality extends across several categories of content within the navigator pane. The search returns results for the names of individual Applications (e.g., Incident), the names of Modules within those applications (e.g., Create New), user-defined Favorites, and automatically tracked navigation History Records. These four types represent the distinct categories of results the filter navigator is designed to return.

A. Names of Applications and Modules: While factually correct, this option is a composite description of options B and C. Given the question asks to choose four and there are five correct concepts presented (A, B, C, D, E), the most precise answer consists of the four distinct, non-overlapping categories.
F. Titles of Dashboard Gauges: The Application Navigator search is strictly for finding navigation items (applications, modules, etc.). It does not index or search for content within pages, such as the titles of gauges or widgets on a dashboard. That function is handled by global search.

1. ServiceNow Product Documentation: UI16 application navigator. In the "Application navigator elements" section

the documentation explicitly lists the components: "Filter"

"All applications tab"

"Favorites tab"

and "History tab". It states

"Use the filter to show matching applications or modules." The filter applies to all tabs

confirming that it searches across applications

modules

favorites

and history.

2. ServiceNow Now Learning: ServiceNow Fundamentals (Tokyo) Participant Guide. In Module 2

"ServiceNow User Interface

" the guide details the Application Navigator. It describes its components

including the filter

the list of applications and modules

the Favorites tab

and the History tab

confirming that all are subject to the filter search. The text specifies

"The filter navigator... allows you to quickly navigate to applications and modules

" and subsequent sections detail the Favorites and History tabs as integral

searchable parts of the same UI element.

The snknowledgeimport role is the specific system-level permission required to grant a user the ability to import articles into a knowledge base. While a user must also have "contribute" access to the target knowledge base, the snknowledgeimport role is what enables the import functionality itself. Users with the knowledgeadmin role also have this capability inherently. This role ensures that only authorized users can perform bulk import operations, maintaining control over the knowledge content.

A. Can contribute: This is a user criteria setting that grants permission to create and edit articles within a specific knowledge base, but it does not grant access to the system's import module.
B. snknowledgecontripute: This is not a valid, standard ServiceNow role. The name appears to be a misspelling.
D. Can import: This is not a standard user criteria option for knowledge bases. Access permissions at the knowledge base level are managed by "Can read" and "Can contribute."

1. ServiceNow Product Documentation: Import a Word document to a knowledge base.

Reference Details: In the "Before you begin" section

it explicitly states

"Role required: snknowledgeimport or knowledgeadmin." This directly confirms that the snknowledgeimport role is required for the import action.

2. ServiceNow Product Documentation: User criteria for knowledge bases.

Reference Details: This document outlines the access controls for knowledge bases

detailing the "Can read" and "Can contribute" options. It makes no mention of a "Can import" user criteria

confirming that option D is incorrect.

3. ServiceNow Product Documentation: Components installed with Knowledge Management.

Reference Details: In the "Roles" table

the snknowledgeimport role is listed with the description: "Can import documents as articles." This confirms the role's specific purpose.

In ServiceNow, scripts are categorized as either client-side or server-side. Client-side scripts execute within the user's web browser and are primarily used to manage the user interface and user experience. Both UI Policies and Client Scripts are client-side mechanisms. UI Policies dynamically change form information or field attributes, while Client Scripts execute on user actions like form loading, changes, or submissions. Both operate directly within the browser to provide a responsive user experience without needing to communicate with the server for every change.

B. Access Control Scripts: These are server-side scripts that run to enforce security and determine a user's permissions to access data before it is sent to the browser.
C. Script Include Scripts: These are reusable libraries of code that execute on the server. They can be called by other server-side scripts or by client-side scripts via GlideAjax, but the execution happens on the server.
D. Business Rule Scripts: These are server-side scripts that execute when records are queried, inserted, updated, or deleted on the server's database.

1. ServiceNow Product Documentation: Client-side scripting. This document explicitly lists UI Policies and Client Scripts as the primary types of scripts that run on the client (browser). It states, "Client-side scripts run on the web browser. You can use client-side scripts to manage the user interface (UI) and user experience (UX)."

2. ServiceNow Product Documentation: Server-side scripts. This document contrasts with client-side scripting and lists Business Rules, Access Controls (ACLs), and Script Includes as scripts that "run on the ServiceNow server or database."

3. ServiceNow Developer Site: ServiceNow Fundamentals Learning Path, Client-Side Scripting Module. This training module details how Client Scripts and UI Policies are used to create the user experience in the browser. It specifies their execution context as the client.

4. ServiceNow Developer Site: ServiceNow Fundamentals Learning Path, Server-Side Scripting Module. This module explains that Business Rules, Script Includes, and Access Controls execute on the server to interact with the database and enforce logic before data is returned to the user's browser.

The Activity Formatter is a standard element on ServiceNow forms, particularly those extended from the Task table (e.g., Incident, Problem, Change). It provides a chronological, time-stamped history of all actions and changes related to a specific record. This includes updates to field values, work notes, additional comments, emails sent/received, and other system-generated events. It is the primary tool for users to track the lifecycle and progress of a task.

A. Sidebar: A sidebar is a general user interface pattern, but it is not the specific name for the element that displays record history on a ServiceNow form.
B. Action Stream: This is not a standard ServiceNow term for a form element. The correct term is Activity Formatter, which displays the activity stream.
C. Action Formatter: This is not a recognized type of formatter in ServiceNow. The correct and official name for the history element is the Activity Formatter.

1. ServiceNow Product Documentation - Utah Release: Activity formatter. This document states, "The activity formatter provides a chronological summary of all activities that have occurred for a specific record." It details how it displays field changes, comments, work notes, and emails.

2. ServiceNow Product Documentation - Utah Release: Formatters. This page explains that formatters are used to add non-field information to a form. It lists the "Activity stream" (which is displayed by the Activity Formatter) as a primary example, stating, "Add an activity stream to a form to show a log of all the changes that have been made to a record."

3. ServiceNow Developer Documentation: UI macros. The Activity Formatter is powered by a UI Macro, typically named activity.xml. This documentation explains how UI macros are used to create custom controls and interfaces, including formatters, on forms.

User Criteria is the designated ServiceNow feature for controlling access to Service Catalog items and categories. It allows administrators to define reusable sets of conditions based on a user's attributes, such as their roles, group memberships, department, or location. These criteria are then applied to a catalog item through the "Available For" and "Not Available For" related lists to grant or deny visibility and the ability to order the item. This provides a flexible and powerful method for managing catalog item entitlements without creating complex ACLs.

A. Can Read Role: This is not a standard ServiceNow feature. Access is managed by User Criteria, which can be based on roles, but not a specific "Can Read Role".
B. Catalog User Role: The catalog role grants general access to the Service Catalog application but does not control the visibility of specific, individual items.
C. Can Order Tab: This is a UI element on the catalog item form where ordering options are configured, not the mechanism for controlling user access to the item itself.

1. ServiceNow Product Documentation: "User criteria for service catalog". This document states, "User criteria records define conditions that are evaluated against user attributes to determine which users can access service catalog items."

2. ServiceNow Product Documentation: "Create or edit a catalog item". In the section describing the catalog item form, it details the "Available For" and "Not Available For" related lists, which are used to "Add or remove user criteria records to control access to a catalog item."

3. ServiceNow Developer Site Learning: "ServiceNow Fundamentals > Build a Service Catalog Item > Secure a Catalog Item". This module explains, "To control which users can see a catalog item, developers add User Criteria to the Available For and Not Available For related lists."