Pass CSA Exam Guide

Workflows in ServiceNow are typically moved between instances using Update Sets. Update Sets serve as a mechanism for capturing customizations and migrating them across different environments, such as Development (Dev) → Test → Production (Prod).

Recording Customizations:

When a workflow is modified or created, its changes are recorded in an Update Set if the Update Set is active.

Capturing Related Records:

Workflows consist of multiple components (e.g., activities, conditions, transitions).

Update Sets capture the Workflow Version and associated Workflow Activities.

Exporting and Importing:

The Update Set containing the workflow is exported from the source instance (e.g., Dev).

It is then imported into the target instance (e.g., Test or Prod).

Commit the Update Set:

After import, the Update Set must be reviewed and committed to apply the changes in the target instance.

B. Workflows are moved using Transform Maps ❌

Incorrect: Transform Maps are used for importing and mapping data from external sources into ServiceNow tables, not for migrating configurations like workflows.

C. Workflows are moved using Application Sets ❌

Incorrect: There is no such thing as "Application Sets" in ServiceNow. However, Applications (Scoped Apps) can be moved using Application Repositories (App Repo) or Update Sets, but this is different from standard Workflow migration.

D. Workflows cannot be moved between instances ❌

Incorrect: Workflows can be moved using Update Sets, and in scoped applications, they can also be packaged with the application.

How Update Sets Work for Workflows?Why Other Options Are Incorrect?

ServiceNow Product Documentation - Update Sets

Update Sets Overview

Moving Customizations Using Update Sets

ServiceNow Workflows

Workflow Management

References from ServiceNow CSA Documentation:

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.

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.

Understanding Service Catalog Items

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.

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)

References from the Certified System Administrator (CSA) Documentation:

In ServiceNow, User Criteria define conditions that determine which users can create, read, write, and retire knowledge articles in a Knowledge Base (KB). User Criteria help enforce access control and ensure that only authorized users can interact with specific knowledge bases.

Control who can read, contribute, edit, or retire knowledge articles.

Based on roles, groups, departments, locations, or custom conditions.

Applied at the Knowledge Base level, affecting all articles within that KB.

Can be combined using "Must match all" or "Match any" logic.

Example 1: Restricting Read Access

A knowledge base for IT Support should be accessible only to IT employees.

User Criteria: Department = IT, OR Role = itil

Only IT employees or ITIL users can read articles in this KB.

Example 2: Controlling Who Can Contribute

Only HR staff should be allowed to create or update HR-related knowledge articles.

User Criteria: Group = HR Team, OR Role = knowledge_manager

Only HR Team members and Knowledge Managers can contribute.

User Criteria is the official term in ServiceNow for defining access control conditions for knowledge articles.

It allows precise control over who can read, create, write, or retire articles.

It is a feature within the Knowledge Management application.

A. User Conditions – Incorrect

No such concept exists in ServiceNow. User Criteria, not "User Conditions," determine knowledge article access.

B. User Info – Incorrect

"User Info" refers to details stored in the sys_user table (e.g., name, email) but does not define knowledge permissions.

D. User Permissions – Incorrect

While permissions exist in ServiceNow (via roles and ACLs), User Criteria specifically manage Knowledge Base access.

ServiceNow Docs: User Criteria for Knowledge Management

ServiceNow CSA Study Guide – Knowledge Management Permissions

ServiceNow Product Documentation: Configuring Knowledge Base Access

Key Features of User Criteria:Examples of User Criteria:Why "C. User Criteria" is the Correct Answer?Explanation of Incorrect Options:References from Certified System Administrator (CSA) Documentation:

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".

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.

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.

ServiceNow Product Documentation → User Administration → sys_user Table

ServiceNow Tables Reference → sys_user

ServiceNow CSA Study Guide → User and Data Administration

Understanding the sys_user Table:Explanation of Incorrect Answers:References from Certified System Administrator (CSA) Documentation: