PowerExams Prepare. Practice. Pass.

ServiceNow CSA — Study Guide

Certified System Administrator. Structured by the six official exam domains (blueprint updated January 2026). Original content mapped to the public exam blueprint — not affiliated with or endorsed by ServiceNow.

The exam is 60 questions in 90 minutes, multiple choice and multiple select. Domain weights below tell you where to spend your study time — Database Management & Platform Security (30%) is by far the heaviest, followed by the two 20% application domains.

Domain 1 — Platform Overview and Navigation (7%)

What it covers: what the Now Platform is, how instances work, and how to move around the Next Experience UI.

ServiceNow is a single-architecture, cloud-based Platform-as-a-Service. Everything — ITSM, HR, CSM, custom apps — runs on one data model and one UI framework, so a record in one application can relate to records in another. Each customer gets one or more instances (separate, isolated copies of the platform). A typical customer has at least a production instance and one or more sub-production instances (dev, test) used to build and validate changes before they are promoted to production.

Next Experience is the modern UI (still the current name — not renamed in recent releases). The older UI16 still exists beneath it, now referred to as Core UI. Key navigation elements:

  • Unified Navigation / Application Navigator — the left-hand filter and menu of applications and modules. Type in the filter to jump quickly; favorites and history tabs speed up repeat navigation.
  • All / Favorites / History menus — replace the older single navigator.
  • Polaris theming gives Next Experience its look; admins can adjust themes.

Know the difference between an application (a packaged set of functionality, e.g., Incident) and a module (a link within an application that opens a list, form, or page).

Domain 2 — Instance Configuration (10%)

What it covers: installing apps and plugins, personalizing the instance, and the common UI surfaces.

Plugins and applications are activated to add functionality. Many are available from the ServiceNow Store; platform plugins are activated in System Definition > Plugins (or via the Store). Some plugins load demo data — admins choose whether to include it.

Personalizing vs. configuring is a key distinction:

  • Personalizing is per-user, low-impact (e.g., a user rearranging their own list columns, setting their own preferences). It does not change the experience for others.
  • Configuring changes the underlying object for everyone (e.g., an admin editing a form layout, adding a field). Configuration is captured in update sets.

Common interfaces you should recognize: the standard UI (Next Experience), forms, lists, dashboards/homepages, and workspaces (configurable, agent-focused interfaces built on UI Builder).

Domain 3 — Configuring Applications for Collaboration (20%)

What it covers: lists, forms, filters, tags, task management, Visual Task Boards, dashboards/Platform Analytics, and notifications. This is heavily about day-to-day admin configuration.

Lists and forms are the two primary record views.

  • A list shows many records; a form shows one record. List controls include column headers (click to sort), the condition builder / filter, the list mechanic breadcrumb, and personalizing columns via the gear/list controls.
  • Filters are built with the condition builder (field → operator → value), can be AND/OR, and can be saved as Favorites or shared. The breadcrumb at the top of a filtered list lets you remove or edit conditions quickly.
  • Tags let users label records for their own quick retrieval; tags can be personal or shared.

Form configuration:

  • Form layout / Form Designer controls which fields appear and their arrangement.
  • Form templates pre-populate field values to speed up record creation.
  • Form sections, related lists, and UI elements (formatters, annotations) round out the form.
  • Saving options: Save (stay on the form), Submit/Update (save and leave), Insert and Insert and Stay (create a copy as a new record).

Task management: ServiceNow's Task table is the parent of Incident, Problem, Change, and many others, so they share fields like Number, State, Assigned to, Priority. Priority is derived from Impact × Urgency via a Priority Data Lookup Rule (Data Lookup & Record Matching) — a lookup table maps each Impact/Urgency combination to a Priority value. Precedence vs. business rules is order-dependent: in the order of execution, before business rules with order < 1000 run before the data-lookup engine, and those with order ≥ 1000 run after it (and can override the looked-up value) — so the lookup does not hold absolute precedence over all business rules.

Visual Task Boards (VTBs) are Kanban-style boards (Freeform, Guided, or Flexible) for managing tasks as cards across lanes.

Platform Analytics is the current umbrella that unifies Reporting and Performance Analytics into one experience. Dashboards present reports and Performance Analytics indicators/widgets. (Use "Platform Analytics" for the product; "Performance Analytics" specifically means the indicator/time-series engine.) Reports are built on a table + a type (bar, pie, list, etc.) and can be scheduled or shared.

Notifications (System Notification > Email) send email based on events or conditions (e.g., when an incident is assigned). They have a When to send, Who will receive, and What it will contain.

Domain 4 — Self Service & Automation (20%)

What it covers: Knowledge Management, Service Catalog, Workflow Studio (Flow Designer), and Virtual Agent.

Knowledge Management organizes articles into Knowledge Bases, controlled by user criteria (who can read/contribute). Articles move through a lifecycle (Draft → Review → Published → Retired) and support feedback, flagging, and versioning.

Service Catalog is the storefront for requestable items and services. Core building blocks:

  • Catalog Items — the things users request.
  • Variables — the questions on the item (types include Single Line Text, Multiple Choice, Select Box, Reference, Checkbox, etc.).
  • Record Producers — create a record on any table from a catalog-style form.
  • Order Guides — bundle multiple items into one ordering flow.
  • The request structure: Request (REQ, sc_request) → Requested Item (RITM, sc_req_item) → Catalog Task (SCTASK, sc_task) — one-to-many at each level (a REQ can hold several RITMs; an RITM can spawn several SCTASKs), not strictly 1:1.

Workflow Studio / Flow Designer is the low-code automation tool. Concepts: Flows (trigger + actions), Subflows (reusable logic), Actions, and triggers (record-based, scheduled, inbound). It largely replaces the legacy graphical Workflow editor for new automation.

Virtual Agent is the conversational chatbot; admins configure topics that guide users through self-service conversations.

Domain 5 — Database Management and Platform Security (30%) — heaviest

What it covers: the data schema, access control (ACLs), importing data, the CMDB/CSDM, the Security Center, and the shared responsibility model. Spend the most time here.

Data schema:

  • Data is stored in tables; each row is a record, each column a field. Every table has a unique sys_id per record.
  • Table extension (inheritance): a child table inherits all fields of its parent and adds its own. Example: Incident, Problem, and Change all extend Task. The CMDB base class is cmdb_ci.
  • Field types matter: String, Choice, Reference, Date/Time, True/False, Journal, etc. A Reference field points to a record on another table; dot-walking lets you traverse from a reference to fields on the related record (e.g., caller_id.email).

Access control (security):

  • Roles are containers of permissions assigned to users (directly or via groups). admin, itil, etc.
  • Access Control Rules (ACLs) secure operations on tables/fields. An ACL is evaluated on table.field for an operation (read, write, create, delete). To grant access, the user must pass the required roles AND the condition AND the script — but within the required-roles list the logic is OR (holding any one listed role satisfies the role check; an empty role list passes that check). For field access ServiceNow uses a two-gate model: the table (row) ACL is evaluated first — if it fails, all fields are denied — and only if it passes is the field ACL evaluated; the user must pass both. (The phrase "most specific to most general" describes how candidate rules are matched to one object within a gate, not the table-then-field sequence.)
  • Contextual security: ACLs are the foundation. If no matching ACL grants access, access is denied by default.

Importing data: the standard path is Import Set → Transform Map → target table.

  • An Import Set is a staging table that temporarily holds incoming rows (from Excel/CSV/JDBC/web service).
  • A Transform Map defines how staging columns map to target table fields, including coalesce (a field used to match existing records so imports update rather than duplicate) and field maps.
  • Data sources define where the data comes from for scheduled/automated imports.

CMDB and CSDM:

  • The CMDB stores Configuration Items (CIs) and their relationships, all extending cmdb_ci.
  • CSDM (Common Service Data Model) is the standard, prescriptive framework for how to structure service and CI data in the CMDB.

Security Center gives a centralized view of the instance's security posture. The Shared Responsibility Model clarifies what ServiceNow secures (the platform/infrastructure) versus what the customer secures (their configuration, data, access, and integrations).

Domain 6 — Data Migration and Integration (13%)

What it covers: UI Policies, Business Rules, update sets, and scripting basics. (Despite the name, this domain is largely about client/server logic and moving configuration between instances.)

UI Policies dynamically change a form in the browser — making fields mandatory, read-only, or visible based on conditions — without writing scripts (though scripts are optional). They run client-side.

Business Rules are server-side scripts that run when records are queried, inserted, updated, or deleted. Timing options:

  • before — modify the record before it's written to the database.
  • after — run logic after the write (e.g., update related records).
  • async — run in the background via a scheduled job.
  • display — run before the form loads to set up g_scratchpad data for client scripts.

Know the difference: UI Policy = client-side form behavior, no/low code; Business Rule = server-side database logic. Client Scripts also run client-side but require scripting.

Update sets capture configuration changes (form layouts, business rules, UI policies, etc.) so they can be moved from a sub-production instance to production. Key points:

  • Data records (like incidents) are not captured by update sets — only configuration. Notably, users, roles, groups, and ACL data records are also not captured by default and must be moved another way.
  • A Default update set exists; you create a named one and make it current before making changes you want captured.
  • Promotion flow: complete the update set → export/retrieve to the target instance → preview (resolve collisions) → commit.

Scripting: ServiceNow uses JavaScript. The two main server-side APIs are GlideRecord (query/insert/update/delete records) and GlideSystem (gs) (utility functions like gs.info(), gs.getUser()). Client-side scripting uses the g_form and g_user APIs.

Fast-recall cheat list

  • Heaviest domain: Database Management & Platform Security (30%).
  • Task table is the parent of Incident/Problem/Change; cmdb_ci is the CMDB base class.
  • Priority = Impact × Urgency (via data lookup).
  • Import path: Import Set → Transform Map (with coalesce) → target table.
  • UI Policy = client-side, no-code form behavior; Business Rule = server-side database logic.
  • Update sets capture configuration, not data; flow is retrieve → preview → commit.
  • Scripting language = JavaScript; GlideRecord (server), g_form (client).
  • Access denied by default unless an ACL grants it; an ACL needs roles and condition and script to pass (but OR within the roles list — any one role). For fields, table ACL first, then field ACL — both must pass.
  • Catalog request structure: REQ → RITM → SCTASK.
  • Personalizing is per-user; configuring changes the object for everyone and is captured in update sets.