1
Q
CSA Exam Domains — CSA Core
A
The major content areas covered by the ServiceNow Certified System Administrator exam: Instance & Data Architecture, User Interface & Navigation, Collaboration, Self-Service & Automation, Database & Application Configuration, Security & Access Control, Reporting & Performance Analytics, and Platform Overview.
Why it matters for CSA: Understanding the exam blueprint helps prioritize study and ensures coverage of all assessed competencies.
Example: Map your study plan to each domain and track progress against the blueprint.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
2
Q
Instance — Platform
A
A single, isolated ServiceNow environment (e.g., dev, test, prod) with its own database and configurations.
Why it matters for CSA: CSA candidates must understand instance separation, cloning, upgrades, and typical environment strategies.
Example: Use a dev instance for configuration, then promote changes via update sets to test and prod.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
3
Q
Release Family — Platform
A
ServiceNow versions are organized into named release families (e.g., Vancouver, Washington DC) with features and fixes.
Why it matters for CSA: CSA requires awareness of upgrade cadence, release notes, and compatibility considerations.
Example: Plan upgrade testing based on release notes and the Store app compatibility list.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
4
Q
Application Scope — Platform
A
Defines the namespace and boundaries for an app, controlling which artifacts are accessible and which scripts can call others.
Why it matters for CSA: Scope affects update set behavior, script include access, and security—key CSA knowledge.
Example: Create a scoped app to encapsulate custom tables and script includes, limiting cross‑app access.
Exam Trap ⚠️: Cross-scope access is restricted—APIs differ; ensure you are in the correct scope and update set.
5
Q
Table — Platform
A
A database object that stores records (rows) with fields (columns). Tables can extend other tables and inherit fields.
Why it matters for CSA: Core to data modeling and configuration tasks on the exam.
Example: The Task [task] table is extended by Incident [incident], Problem [problem], and Change [change_request].
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
6
Q
Field — Platform
A
A column within a table that stores a specific type of data (string, integer, reference, choice, etc.).
Why it matters for CSA: Field configuration and dictionary elements are common CSA topics.
Example: Add a Choice field to Incident for business impact with values Low/Medium/High.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
7
Q
Record — Platform
A
A single row in a table representing one data entity.
Why it matters for CSA: Navigating, editing, and managing records are foundational CSA skills.
Example: Open an Incident record and update state and assignment group via the form.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
8
Q
Dictionary — Platform
A
Metadata definitions for tables and fields, including types, attributes, and behaviors.
Why it matters for CSA: CSA covers dictionary entries/overrides, field attributes, and configuration best practices.
Example: Add a Dictionary Override on Incident to make a field mandatory only on that table.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
9
Q
Dictionary Override — Platform
A
An override that changes field behavior on a child table when the field is inherited from a parent table.
Why it matters for CSA: Important when dealing with extended tables such as Task.
Example: Make Short description mandatory on Incident but not on Change via a dictionary override.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
10
Q
Extended Table — Platform
A
A table that inherits fields and behavior from a parent table, allowing specialization.
Why it matters for CSA: CSA expects knowledge of extension, inheritance, and the Task hierarchy.
Example: Problem [problem] extends Task [task] and adds root cause specific fields.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
11
Q
Reference Field — Platform
A
A field that points to a record in another table, creating a relationship.
Why it matters for CSA: Used heavily across the platform; knowing reference qualifiers is exam‑relevant.
Example: Caller on Incident references the User [sys_user] table.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
12
Q
Choice Field — Platform
A
A field with predefined selectable values controlled by the Choice table.
Why it matters for CSA: Choice maintenance and translation are common tasks.
Example: Add a new Priority choice and map to an SLA policy.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
13
Q
Schema Map — Platform
A
A visual representation of table relationships including extensions and references.
Why it matters for CSA: CSA candidates should know how to explore table relationships.
Example: Open the Schema Map for Task to see child tables like Incident, Problem, Change.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
14
Q
Form — UI/UX
A
The UI used to view or edit a single record, with sections, related lists, and form layout.
Why it matters for CSA: Forms are core to day‑to‑day work and configuration.
Example: Personalize form layout to show Additional comments and Assignment group prominently.
Exam Trap ⚠️: Personalize affects only you; Configure changes system-wide—avoid unintended global changes.
15
Q
List — UI/UX
A
A tabular view of multiple records with filtering, sorting, and list controls.
Why it matters for CSA: List navigation, filters, and bulk edits are CSA basics.
Example: Use list filters to find P1 incidents assigned to your group and update via list edit.
Exam Trap ⚠️: Personalize affects only you; Configure changes system-wide—avoid unintended global changes.
16
Q
Filter — UI/UX
A
Criteria that constrain the records displayed in a list or report.
Why it matters for CSA: CSA tests using conditions, breadcrumbs, and saving filters.
Example: Create a filter: Priority is 1 ‑ Critical AND Assignment group is Service Desk.
Exam Trap ⚠️: Personalize affects only you; Configure changes system-wide—avoid unintended global changes.
17
Q
Breadcrumbs — UI/UX
A
Clickable parts of a filter that let users quickly remove or alter conditions.
Why it matters for CSA: Useful for efficient navigation—often covered in UI basics.
Example: Click a breadcrumb to remove the Assignment group condition and widen results.
Exam Trap ⚠️: Personalize affects only you; Configure changes system-wide—avoid unintended global changes.
18
Q
Module — UI/UX
A
A navigational link in the Application Navigator that opens a list, form, or page.
Why it matters for CSA: Understanding modules vs. applications is foundational.
Example: Create a module for Open Incidents filtered by your assignment group.
Exam Trap ⚠️: Personalize affects only you; Configure changes system-wide—avoid unintended global changes.
19
Q
Application (Navigator) — UI/UX
A
A grouping of modules in the Application Navigator representing a functional area.
Why it matters for CSA: Knowing how to organize and control visibility is important.
Example: Add the Incident application to favorites for quick access.
Exam Trap ⚠️: Personalize affects only you; Configure changes system-wide—avoid unintended global changes.
20
Q
Update Set — Platform
A
A container that captures configuration changes for moving between instances.
Why it matters for CSA: Critical for promoting changes across dev/test/prod—high CSA relevance.
Example: Record changes in an update set, complete it, export XML, and import to test/prod.
Exam Trap ⚠️: Update Sets capture configuration, not data—preview for collisions before commit; never move records like Incidents.
21
Q
Update Source — Platform
A
Defines an origin instance for retrieving update sets into a target instance.
Why it matters for CSA: Understanding retrieval and preview/commit is part of CSA.
Example: Set up an Update Source to pull update sets from dev into test.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
22
Q
Preview/Commit — Platform
A
Steps to validate (preview) and apply (commit) update set changes on a target instance.
Why it matters for CSA: Knowledge of collisions and resolution is tested.
Example: Preview shows collisions; resolve then commit to apply changes safely.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
23
Q
Collision — Platform
A
A conflict during update set preview when a target has changes that differ from incoming updates.
Why it matters for CSA: CSA covers identifying and resolving collisions.
Example: Use the Compare UI to merge or back out overlapping dictionary updates.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
24
Q
ACL — Security/Access
A
Access Control List rule that grants or denies access to table/field/record operations based on roles, conditions, and scripts.
Why it matters for CSA: Security fundamentals are central to CSA.
Example: Create a table‑level read ACL for Incident that requires the itil role and department match.
Exam Trap ⚠️: Do not forget field ACLs—they can block access even if table ACL allows it.
25
Role — Security/Access
A collection of permissions that grant access to applications, modules, and records.
Why it matters for CSA: User/role/group management is a key CSA topic.
Example: Assign itil to service desk agents to access ITSM records and actions.
Exam Trap ⚠️: Check role, condition, and script—all must evaluate to true; watch Admin override settings.
26
Group — Security/Access
A set of users often used for assignment, approvals, and access control.
Why it matters for CSA: Groups power assignment and flow routing.
Example: Create an Assignment Group for Network Operations and link approvers.
Exam Trap ⚠️: Check role, condition, and script—all must evaluate to true; watch Admin override settings.
27
User — Security/Access
An identity in the sys_user table representing a person or system account.
Why it matters for CSA: User records, authentication, and roles are CSA essentials.
Example: Onboard a new analyst by creating a user and granting itil and sn_incident_write roles.
Exam Trap ⚠️: Check role, condition, and script—all must evaluate to true; watch Admin override settings.
28
Authentication — Security/Access
The process of verifying user identity, supporting methods like SSO, LDAP, OAuth, and local login.
Why it matters for CSA: CSA expects familiarity with common auth integrations.
Example: Integrate Azure AD SSO via SAML to streamline authentication.
Exam Trap ⚠️: Check role, condition, and script—all must evaluate to true; watch Admin override settings.
29
Authorization — Security/Access
Granting or denying access to resources after authentication, usually via roles and ACLs.
Why it matters for CSA: Core to protecting data and functions.
Example: Restrict change approval to CAB members using role‑based ACLs.
Exam Trap ⚠️: Check role, condition, and script—all must evaluate to true; watch Admin override settings.
30
Business Rule (BR) — Platform
Server‑side script that runs when records are inserted, updated, deleted, or queried.
Why it matters for CSA: CSA covers when to use BRs vs. other automation and their execution order.
Example: Use a before insert BR to set default priority based on impact and urgency.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
31
Client Script — Platform
Browser‑side script (onChange, onLoad, onSubmit, onCellEdit) to manage form behavior and validation.
Why it matters for CSA: UI behavior and data integrity are frequent CSA topics.
Example: Use onChange to dynamically show/hide fields based on category.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
32
UI Policy — UI/UX
Rule that dynamically controls form behavior (mandatory, visible, read‑only) without scripting.
Why it matters for CSA: Preferred over client scripts when possible; commonly tested.
Example: Create a UI Policy to make Closure notes mandatory when State is Resolved.
Exam Trap ⚠️: Personalize affects only you; Configure changes system-wide—avoid unintended global changes.
33
Data Policy — Platform
Server‑side enforcement of field requirements on all data entry points, not just forms.
Why it matters for CSA: Ensures integrity even via imports/integrations.
Example: Use a data policy to require Serial Number for Hardware CIs on import.
Exam Trap ⚠️: Do not confuse Data Policies with UI Policies—Data Policies apply on server side across all entry points.
34
Script Include — Platform
Reusable server-side script library callable from BRs, Scripted APIs, and other scripts.
Why it matters for CSA: Scope and access (client callable) are CSA considerations.
Example: Create a Script Include with utility functions for calculating business duration.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
35
GlideRecord — Platform
Server‑side API for database operations: querying, inserting, updating, and deleting records.
Why it matters for CSA: Core scripting concept on CSA.
Example: Use GlideRecord to query open incidents older than 7 days and notify owners.
Exam Trap ⚠️: GlideRecord runs server-side—use GlideAjax for client-to-server calls; remember to call .next() in loops.
36
GlideAjax — Platform
Client‑to‑server call mechanism to execute server logic from client scripts asynchronously.
Why it matters for CSA: Bridges client and server—key in UI performance.
Example: Use GlideAjax to fetch CI ownership info without reloading the form.
Exam Trap ⚠️: GlideAjax requires a client-callable Script Include; avoid heavy queries on form load.
37
UI Action — UI/UX
Buttons, links, and context menu items that perform actions via scripts or navigation.
Why it matters for CSA: CSA covers visibility conditions and 'Action name' usage.
Example: Add a 'Escalate' UI Action to change priority and notify the on‑call group.
Exam Trap ⚠️: Personalize affects only you; Configure changes system-wide—avoid unintended global changes.
38
UI Macro — UI/UX
Reusable UI fragments written in Jelly used to render custom form/list UI components.
Why it matters for CSA: Legacy but still seen—good awareness for CSA.
Example: Insert a UI Macro for custom banner messages on forms.
Exam Trap ⚠️: Personalize affects only you; Configure changes system-wide—avoid unintended global changes.
39
UI Formatter — UI/UX
A UI component that renders non‑field information on a form header/footer.
Why it matters for CSA: Know when to add vs. script.
Example: Add the Approval Summaries formatter to Change Request forms.
Exam Trap ⚠️: Personalize affects only you; Configure changes system-wide—avoid unintended global changes.
40
Notification — Platform
Email or push message sent based on events, conditions, or flows.
Why it matters for CSA: CSA covers notification triggers, templates, and subscriptions.
Example: Send an email to the Caller when Incident state changes to Resolved.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
41
Subscription — Platform
User opt‑in to receive notifications for specific events or records.
Why it matters for CSA: Relevant to collaboration features.
Example: Allow users to subscribe to Knowledge Article updates.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
42
Event — Platform
A system occurrence logged in the Event [sysevent] table that can trigger notifications or scripts.
Why it matters for CSA: Understanding events is crucial for automation.
Example: Fire an event 'incident.escalated' and handle it with a notification.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
43
Scheduler — Platform
Engine that executes scheduled jobs, reports, and maintenance tasks.
Why it matters for CSA: CSA candidates should know scheduled jobs' purpose.
Example: Create a Scheduled Job to nightly close resolved incidents older than 7 days.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
44
Scheduled Job — Platform
A time‑based job (scheduled script execution) run on a cadence.
Why it matters for CSA: Often used for cleanup or batch processes.
Example: Run a weekly job to rebuild service maps or recalc SLAs.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
45
Flow Designer — Platform
No‑code/low‑code automation designer replacing many legacy workflows.
Why it matters for CSA: CSA includes creating flows, actions, subflows, and triggers.
Example: Build a flow that triggers on Incident creation to assign and notify based on category.
Exam Trap ⚠️: Avoid mixing legacy Workflow with Flow Designer artifacts—choose one approach per process.
46
Workflow (Legacy) — Platform
Legacy graphical workflow engine for orchestrating activities; deprecated in many areas in favor of Flow Designer.
Why it matters for CSA: Know legacy presence but prefer Flow Designer for new automation.
Example: Legacy Change workflow handling approvals and CAB review.
Exam Trap ⚠️: Legacy Workflow is deprecated in many areas—Flow Designer is preferred for new automation.
47
Subflow — Platform
A reusable Flow Designer component called from flows or other subflows.
Why it matters for CSA: Encouraged for modularity and reuse.
Example: Create a subflow 'Notify Assignment Group' used by multiple task flows.
Exam Trap ⚠️: Avoid mixing legacy Workflow with Flow Designer artifacts—choose one approach per process.
48
Action (Flow Designer) — Platform
A step in Flow Designer that performs a function, either out-of-box or custom-built.
Why it matters for CSA: Key to building maintainable automations.
Example: Use the 'Create Record' action to open a Problem from a P1 Incident.
Exam Trap ⚠️: Avoid mixing legacy Workflow with Flow Designer artifacts—choose one approach per process.
49
IntegrationHub — Integration
ServiceNow capability that provides spokes and actions to integrate with external systems.
Why it matters for CSA: CSA should recognize its role in integrations.
Example: Use the Microsoft Teams spoke to post a message on incident assignment.
Exam Trap ⚠️: Avoid hard-coding credentials—use connection & credential aliases and test with limited data.
50
Spoke — Integration
A collection of IntegrationHub actions for a specific system or service.
Why it matters for CSA: Knowledge helps select the right integration approach.
Example: Use the Slack spoke to create a channel and invite resolvers for a major incident.
Exam Trap ⚠️: Avoid hard-coding credentials—use connection & credential aliases and test with limited data.
51
REST API — Integration
Web service interface following REST principles for CRUD operations and business logic execution.
Why it matters for CSA: APIs are essential for data exchange.
Example: Expose a Scripted REST API to query incidents by CI and priority.
Exam Trap ⚠️: Avoid hard-coding credentials—use connection & credential aliases and test with limited data.
52
SOAP API — Integration
A web service protocol supported for legacy integrations.
Why it matters for CSA: CSA should be aware though REST is preferred.
Example: Consume a SOAP web service to create catalog requests from an ERP.
Exam Trap ⚠️: Avoid hard-coding credentials—use connection & credential aliases and test with limited data.
53
Import Set — Platform
Staging table and mechanism for bringing external data into ServiceNow.
Why it matters for CSA: CSA covers import sets, data sources, and transform maps.
Example: Load a CSV of users into an import set, then transform into sys_user.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
54
Data Source — Platform
Configuration defining where import data comes from (file, JDBC, LDAP, etc.).
Why it matters for CSA: Selecting the right source is a CSA task.
Example: Configure an SFTP data source to import asset data nightly.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
55
Transform Map — Platform
Defines field mappings and scripts to move data from import set to target tables.
Why it matters for CSA: Central to data imports—high CSA relevance.
Example: Map 'user_name' to 'user_name' and script to set 'active=true' on create.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
56
Coalesce — Platform
A transform map setting that treats a field as a unique key to update existing records instead of inserting duplicates.
Why it matters for CSA: Prevents duplicates—an exam staple.
Example: Coalesce on email to update users if they already exist.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
57
MID Server — Integration
A lightweight Java application that runs on a local network to facilitate Discovery, IntegrationHub, and Orchestration.
Why it matters for CSA: Important for integrations and Discovery coverage.
Example: Install a MID Server in the DMZ to reach on‑prem systems for Discovery.
Exam Trap ⚠️: Avoid hard-coding credentials—use connection & credential aliases and test with limited data.
58
CMDB — Platform
Configuration Management Database storing CIs and relationships to support ITSM processes.
Why it matters for CSA: CSA includes CMDB structure and data quality.
Example: Use the CMDB CI Class Manager to review CI classes and attributes.
Exam Trap ⚠️: CMDB stores configuration items and relationships—not incidents or tasks; use IRE to avoid duplicates.
59
CI — Platform
Configuration Item—an asset, service component, or logical entity tracked in the CMDB.
Why it matters for CSA: CIs underpin Incident, Problem, and Change processes.
Example: Link an Incident to the affected CI to enable impact analysis and outage tracking.
Exam Trap ⚠️: CMDB stores configuration items and relationships—not incidents or tasks; use IRE to avoid duplicates.
60
CI Class — Platform
A type/category of CIs defining attributes and behaviors in the CMDB hierarchy.
Why it matters for CSA: CSA expects understanding of CI classes and inheritance.
Example: Server, Database, Application are classes extending cmdb_ci.
Exam Trap ⚠️: CMDB stores configuration items and relationships—not incidents or tasks; use IRE to avoid duplicates.
61
Discovery — Platform
Automated process to identify CIs and populate the CMDB using probes and sensors via a MID Server.
Why it matters for CSA: Key for CMDB accuracy—CSA should know basics.
Example: Run Discovery on the 10.0.0.0/24 IP range to find Windows Servers.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
62
Service Mapping — Platform
Maps application services by tracing traffic from entry points to dependencies for impact analysis.
Why it matters for CSA: Awareness of service mapping enhances incident/change impact assessment.
Example: Create a map for the Customer Portal service to visualize upstream databases.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
63
Identification & Reconciliation — Platform
Processes ensuring unique CI records and authoritative sources win in data conflicts.
Why it matters for CSA: Critical to maintain CMDB integrity.
Example: Configure IRE to prefer Discovery for hardware attributes over imports.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
64
CMDB Health — Reporting/Analytics
Metrics and dashboards for completeness, correctness, and compliance of CMDB data.
Why it matters for CSA: CSA should know quality dimensions and remediation.
Example: Use CMDB Health to track required attributes coverage for Server class.
Exam Trap ⚠️: CMDB stores configuration items and relationships—not incidents or tasks; use IRE to avoid duplicates.
65
Service Catalog — Platform
A curated list of services and items end users can request via the portal.
Why it matters for CSA: CSA covers catalog items, variables, workflows, and request fulfillment.
Example: Create a catalog item 'Request Laptop' with variables, approvals, and task fulfillment.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
66
Catalog Item — Platform
An orderable item in the Service Catalog with variables and fulfillment.
Why it matters for CSA: Core to self‑service automation topics.
Example: Build a catalog item that provisions a mailbox via IntegrationHub.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
67
Record Producer — Platform
A catalog item that creates a record in any table using user‑friendly questions.
Why it matters for CSA: Important for simplifying data capture.
Example: Use a record producer to submit an Incident from the portal with tailored questions.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
68
Order Guide — Platform
A guided ordering experience that bundles multiple catalog items.
Why it matters for CSA: CSA should recognize its use for complex requests.
Example: Create an onboarding order guide that includes laptop, software, and access requests.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
69
Variable — Platform
A question/field on a catalog item or record producer capturing user input.
Why it matters for CSA: Variables and sets are common configuration tasks.
Example: Add a Multiple Choice variable for Laptop model; group variables in a Variable Set.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
70
RITM — Platform
Requested Item—child of a Request representing a single item ordered.
Why it matters for CSA: Acronym knowledge is tested and used daily.
Example: Fulfill an RITM by completing its associated Catalog Task(s).
Exam Trap ⚠️: REQ is the parent request; RITM is the requested item; SCTASK fulfills the RITM—three different records.
71
REQ — Platform
Request—the parent record that groups one or more Requested Items.
Why it matters for CSA: Ties to request lifecycle understanding.
Example: Track overall request status at the REQ level while RITMs progress independently.
Exam Trap ⚠️: REQ is the parent request; RITM is the requested item; SCTASK fulfills the RITM—three different records.
72
SCTASK — Platform
Catalog Task—a task created to fulfill a Requested Item.
Why it matters for CSA: CSA should know task hierarchy and relationships.
Example: Technicians complete SCTASKs like 'Install software' to progress the RITM.
Exam Trap ⚠️: REQ is the parent request; RITM is the requested item; SCTASK fulfills the RITM—three different records.
73
Knowledge Base (KB) — Platform
Repository of articles for self-help and knowledge sharing (often abbreviated as KB).
Why it matters for CSA: Knowledge management supports deflection and quality.
Example: Publish a KB article on VPN setup and attach it to resolved incidents.
Exam Trap ⚠️: Work notes are usually internal; Additional comments are customer-visible—don’t paste internal info into KB end-user sections.
74
Article — Platform
A knowledge record that contains solutions, FAQs, or procedures.
Why it matters for CSA: Part of Knowledge lifecycle on CSA.
Example: Move an article from Draft to Published after peer review and approval.
Exam Trap ⚠️: Work notes are usually internal; Additional comments are customer-visible—don’t paste internal info into KB end-user sections.
75
Incident — ITSM/Process
An unplanned interruption or reduction in quality of an IT service.
Why it matters for CSA: Core ITSM process heavily represented in CSA.
Example: Log, categorize, prioritize, assign, resolve, and close incidents with proper comms.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
76
Problem — ITSM/Process
The underlying cause of one or more incidents.
Why it matters for CSA: CSA must distinguish Incident vs. Problem and their workflows.
Example: Open a Problem for recurring VPN outages; run RCA and implement a fix.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
77
Change Request — ITSM/Process
A request to add, modify, or remove anything that could affect services.
Why it matters for CSA: Change workflows, approvals, and risk are CSA topics.
Example: Submit a Standard Change for routine patching with pre‑approved steps.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
78
Request (Service) (SR) — ITSM/Process
A user‑initiated request for information, advice, or access via the service catalog.
Why it matters for CSA: Request vs. Incident is a common CSA question.
Example: User requests access to SharePoint; RITM flows through approvals and fulfillment.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
79
Task — Platform
Generic work unit; many process records extend Task with lifecycle fields like state, priority, and assignment.
Why it matters for CSA: Understanding inheritance from Task is crucial.
Example: Incident, Problem, and Change all inherit Task fields like Assignment group.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
80
Assignment Group — Platform
Group responsible for working on a task.
Why it matters for CSA: CSA should know assignment rules and group use.
Example: Configure Assignment Rules to auto‑assign Incidents by category.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
81
Assignment Rule — Platform
Rule that sets assignment group or assignee based on conditions.
Why it matters for CSA: Important for automation and accuracy.
Example: Route Network incidents to 'Network Ops' using Assignment Rules.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
82
Priority — ITSM/Process
A value derived from impact and urgency determining task order.
Why it matters for CSA: CSA expects knowledge of priority matrix and SLAs.
Example: Set P1 for widespread outage; triggers shorter SLA targets.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
83
Impact — ITSM/Process
The business effect of an issue (e.g., number of users or criticality).
Why it matters for CSA: Used with urgency to set priority.
Example: Set Impact = High when a Tier‑1 service is affected.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
84
Urgency — ITSM/Process
How quickly resolution is required.
Why it matters for CSA: Combines with impact to set priority.
Example: Urgency = High for executive‑affecting incidents.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
85
SLA — ITSM/Process
Service Level Agreement—commitments to response and resolution times.
Why it matters for CSA: CSA includes SLA definitions and engines.
Example: Attach an SLA definition to Incident to track resolution within 4 business hours.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
86
OLA — ITSM/Process
Operational Level Agreement—internal commitments between support groups.
Why it matters for CSA: Understanding OLA vs. SLA is useful for managers.
Example: Define an OLA for Network and Security teams to handoff within 1 hour.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
87
Underpinning Contract (UC) — ITSM/Process
Contract with a third‑party supplier supporting an SLA.
Why it matters for CSA: Important in supplier management context.
Example: Link a telco UC to the Network service to align outage penalties.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
88
CAB — ITSM/Process
Change Advisory Board—group that assesses, prioritizes, and schedules changes.
Why it matters for CSA: Change governance is part of CSA knowledge.
Example: Set weekly CAB meeting for review of Normal changes and approvals.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
89
CI Relationship — Platform
Links between CIs representing dependencies and containment.
Why it matters for CSA: Supports impact analysis—core CMDB use.
Example: Define Runs on :: Hosted on between Application and Server.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
90
Service Offering — Platform
A specific instance of a business service with defined SLAs and costs.
Why it matters for CSA: Used in Catalog, CMDB, and SLAs.
Example: Attach an SLA to the 'Email Gold' service offering for execs.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
91
Business Service — Platform
A top‑level service provided to the business and tracked in CMDB/service portfolio.
Why it matters for CSA: Key to aligning IT with business outcomes.
Example: Create a Business Service 'Customer Portal' with owning group and offerings.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
92
Service Portfolio — Platform
Catalog of services across pipeline, live, and retired states.
Why it matters for CSA: CSA awareness helps with service lifecycle.
Example: Maintain statuses: 'In development', 'Live', 'Retired'.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
93
Service Owner — ITSM/Process
Role accountable for service quality and performance.
Why it matters for CSA: Governance and approvals may hinge on this role.
Example: Service Owner approves changes and reviews SLAs monthly.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
94
Stakeholder — ITSM/Process
Person or group with interest in service outcomes.
Why it matters for CSA: CSA includes collaboration and communications.
Example: Notify stakeholders of major incident via comms plan template.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
95
Major Incident — ITSM/Process
An incident with significant business impact requiring expedited handling.
Why it matters for CSA: Major incident management is examined.
Example: Trigger MIM process when P1 outage affects multiple regions.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
96
Root Cause Analysis (RCA) — ITSM/Process
Systematic investigation to find the underlying cause of problems.
Why it matters for CSA: Quality improvement depends on solid RCA.
Example: Use fishbone and 5‑Whys to complete RCA and attach to Problem record.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
97
Known Error — ITSM/Process
A problem that has been analyzed and has a documented root cause and workaround.
Why it matters for CSA: Feeds Knowledge and rapid incident resolution.
Example: Create a Known Error DB entry with a workaround article.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
98
Workaround — ITSM/Process
A temporary solution that reduces or eliminates the impact of an incident or problem.
Why it matters for CSA: CSA expects the distinction from permanent fix.
Example: Provide registry fix for printer issue while awaiting driver patch.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
99
Change Type — ITSM/Process
Standard, Normal, and Emergency categories defining risk/approval path.
Why it matters for CSA: Change lifecycle questions are common.
Example: Use Standard change template for routine password policy update.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
100
Risk Assessment — ITSM/Process
Evaluation of likelihood and impact to determine change risk.
Why it matters for CSA: Supports approval and scheduling.
Example: Automate risk based on CI criticality and blackout windows.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
101
Blackout Window — ITSM/Process
Time periods during which changes are restricted.
Why it matters for CSA: Scheduling constraints are operationally important.
Example: Define blackout during end‑of‑month financial close.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
102
Maintenance Window — ITSM/Process
Approved timeframe for planned changes.
Why it matters for CSA: Helps coordination and comms.
Example: Set weekly Saturday 1–3 AM window for server patching.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
103
Approval — ITSM/Process
Formal authorization for a change, request, or article.
Why it matters for CSA: CSA covers approval records and workflows.
Example: Add Manager approval for access requests over privileged groups.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
104
Delegation — Security/Access
Temporarily assigning approvals or tasks to another user.
Why it matters for CSA: Ensures continuity during absence.
Example: Set delegation during a Service Owner's holiday to a deputy.
Exam Trap ⚠️: Check role, condition, and script—all must evaluate to true; watch Admin override settings.
105
Impersonate — Security/Access
Admin function to act as another user for testing and troubleshooting.
Why it matters for CSA: Useful for verifying role‑based access.
Example: Impersonate a requester to test portal visibility of items.
Exam Trap ⚠️: Impersonation skips personalizations—retest with a real user when troubleshooting layout vs access issues.
106
Domain Separation — Security/Access
Logical partitioning of data, processes, and administration for multi‑tenant use.
Why it matters for CSA: Awareness is useful for MSP scenarios.
Example: Separate government and commercial domains with distinct data policies.
Exam Trap ⚠️: Check role, condition, and script—all must evaluate to true; watch Admin override settings.
107
Encryption Context — Security/Access
Configuration for field‑level encryption using keys and contexts.
Why it matters for CSA: CSA should know encrypted field behaviors.
Example: Encrypt PHI fields in HR or ITSM tables with dedicated context.
Exam Trap ⚠️: Check role, condition, and script—all must evaluate to true; watch Admin override settings.
108
ACL Types — Security/Access
Table ACLs govern create, read, write, delete; field ACLs govern field‑level operations; and 'record' ACLs target specific records.
Why it matters for CSA: Granularity of access is an exam theme.
Example: Create a field read ACL to hide 'Work notes' from non‑ITIL roles.
Exam Trap ⚠️: Do not forget field ACLs—they can block access even if table ACL allows it.
109
Conditions — Platform
Logical expressions used across the platform (filters, ACLs, SLAs, notifications).
Why it matters for CSA: Condition builders appear in many areas of CSA.
Example: Use condition builder 'State is Resolved' to trigger closure notification.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
110
Dot‑Walking — Platform
Referencing fields on referenced records (e.g., caller_id.department).
Why it matters for CSA: Common in reports, mail scripts, and conditions.
Example: Use dot‑walk to show Caller > Company on an Incident report.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
111
Mail Script — Platform
Script snippets used in notification templates to render dynamic content.
Why it matters for CSA: CSA should know where and how to use them.
Example: Add a mail script to list related incidents in a resolution email.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
112
Template — Platform
Predefined values applied to new records to speed data entry and standardize fields.
Why it matters for CSA: Useful for accuracy and speed.
Example: Create an Incident template for 'Email access issue' with default category/subcategory.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
113
Data Policy vs UI Policy — Platform
UI Policies affect forms in browser; Data Policies enforce rules at server‑side for all entry points.
Why it matters for CSA: CSA comparative knowledge.
Example: Use Data Policy to ensure mandatory fields are enforced on imports.
Exam Trap ⚠️: UI Policies affect forms only; Data Policies enforce rules on all entry points (imports, integrations, API).
114
Form Design — UI/UX
Modern interface for arranging form fields, sections, and related lists.
Why it matters for CSA: CSA includes form configuration.
Example: Use Form Designer to add a new 'Business Justification' section.
Exam Trap ⚠️: Personalize affects only you; Configure changes system-wide—avoid unintended global changes.
115
Related List — UI/UX
A list on a form showing records related to the current record via relationships.
Why it matters for CSA: Helps navigation and context.
Example: Expose 'Affected CIs' related list on Change.
Exam Trap ⚠️: Personalize affects only you; Configure changes system-wide—avoid unintended global changes.
116
View — UI/UX
A form layout variant (e.g., Default, Mobile) for different audiences or devices.
Why it matters for CSA: CSA covers creating and switching views.
Example: Create a 'Major Incident' view highlighting business impact and comms.
Exam Trap ⚠️: Personalize affects only you; Configure changes system-wide—avoid unintended global changes.
117
List Layout — UI/UX
Configuration of visible columns and order in a list view.
Why it matters for CSA: Productivity and adoption depend on good layouts.
Example: Add Priority, State, Assignment group, and Updated to Incident list.
Exam Trap ⚠️: Personalize affects only you; Configure changes system-wide—avoid unintended global changes.
118
Personalize vs Configure — UI/UX
Personalize affects only the current user; Configure changes system‑wide.
Why it matters for CSA: Avoid accidental global changes—a common CSA pitfall.
Example: Personalize a list filter for yourself; use Configure List Layout for global.
Exam Trap ⚠️: Personalize affects only you; Configure changes system-wide—avoid unintended global changes.
119
System Logs — Platform
Records of platform events, errors, and debug messages.
Why it matters for CSA: CSA includes troubleshooting basics.
Example: Use System Logs > All to view script errors after a failed transform.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
120
Script Debugger — Platform
Tool to step through server‑side scripts like business rules.
Why it matters for CSA: Understanding debugging increases reliability.
Example: Set breakpoints to debug a before update BR that mis‑sets priority.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
121
Studio — Platform
IDE‑like development environment for building scoped applications.
Why it matters for CSA: CSA awareness for app development flows.
Example: Open Studio to create tables, forms, and UI in a new scoped app.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
122
Guided Setup — Platform
Task‑based wizards that help configure applications like ITSM and CMDB.
Why it matters for CSA: Saves time and ensures consistency—exam relevant.
Example: Use ITSM Guided Setup to configure incident categories and SLAs.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
123
ATF — Platform
Automated Test Framework—tool to create and run automated tests for configurations and customizations.
Why it matters for CSA: CSA should know its purpose and benefits.
Example: Create ATF tests to validate Incident form loads and required fields.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
124
Edge Encryption — Security/Access
Client‑side encryption that keeps data encrypted in transit and at rest, decrypted only at the edge.
Why it matters for CSA: Security options awareness may be assessed.
Example: Use Edge Encryption for sensitive PII fields submitted from portal.
Exam Trap ⚠️: Check role, condition, and script—all must evaluate to true; watch Admin override settings.
125
Delegated Development — Security/Access
Allows admins to grant specific development permissions in a scoped app without full admin rights.
Why it matters for CSA: Supports least privilege development.
Example: Enable delegated dev so catalog owners can modify flows in their scope.
Exam Trap ⚠️: Check role, condition, and script—all must evaluate to true; watch Admin override settings.
126
Update Set Preview Problems — Platform
Issues detected during update set preview such as missing dependencies or collisions.
Why it matters for CSA: Critical to safe promotions.
Example: Resolve missing table dependency before committing the update set.
Exam Trap ⚠️: Update Sets capture configuration, not data—preview for collisions before commit; never move records like Incidents.
127
Dependency (Update) — Platform
An artifact required by another change (e.g., a script include used by a BR).
Why it matters for CSA: CSA includes dependency awareness.
Example: Include referenced Script Include in the same update set as the BR.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
128
Scoped vs. Global — Platform
Global scope allows cross-app access; scoped apps encapsulate artifacts and restrict access.
Why it matters for CSA: Affects security and script access.
Example: Build customizations in scoped apps to avoid collisions with global artifacts.
Exam Trap ⚠️: Cross-scope access is restricted—APIs differ; ensure you are in the correct scope and update set.
129
ACL Evaluation Order — Security/Access
ACLs evaluate from most specific to least; all matching rules must grant access for operation to be allowed.
Why it matters for CSA: Understanding order prevents misconfigurations.
Example: Ensure field‑level ACL doesn't block access granted at table level.
Exam Trap ⚠️: All matching ACLs must grant access; evaluation goes most specific to least specific.
130
Role Inheritance — Security/Access
Roles can contain other roles, granting cumulative permissions.
Why it matters for CSA: Explains why users gain access indirectly.
Example: itil_admin includes itil; assignment of parent grants child implicitly.
Exam Trap ⚠️: Check role, condition, and script—all must evaluate to true; watch Admin override settings.
131
Impersonation Testing — Security/Access
Verifying UI and data access by impersonating target roles.
Why it matters for CSA: Ensures correct access controls.
Example: Impersonate a requester to verify portal sees only their incidents.
Exam Trap ⚠️: Check role, condition, and script—all must evaluate to true; watch Admin override settings.
132
Form UI Actions Visibility — UI/UX
Conditions and roles determine when buttons appear on forms.
Why it matters for CSA: CSA often tests visibility logic.
Example: Show 'Resolve' only when State is In Progress and user has itil role.
Exam Trap ⚠️: Personalize affects only you; Configure changes system-wide—avoid unintended global changes.
133
Inbound Email Action — Integration
Server-side logic that processes inbound emails to create or update records.
Why it matters for CSA: Supports email‑based ticketing.
Example: Create an inbound action to add Work notes when subject contains INC number.
Exam Trap ⚠️: Avoid hard-coding credentials—use connection & credential aliases and test with limited data.
134
Outbound Email — Integration
Email sent by notifications, flows, or scripts.
Why it matters for CSA: Control templates and recipients for clarity.
Example: Notify Caller when assignment changes with details from the record.
Exam Trap ⚠️: Avoid hard-coding credentials—use connection & credential aliases and test with limited data.
135
Report — Reporting/Analytics
A visualization of data (list, chart, pivot) saved for reuse and sharing.
Why it matters for CSA: CSA includes how to build and share reports.
Example: Build a bar chart of Incidents by Category for last 30 days.
Exam Trap ⚠️: Reports run in a user context—permissions affect visible data; set “Run as” carefully.
136
Performance Analytics (PA) — Reporting/Analytics
Time‑series metrics and KPIs with scorecards and dashboards.
Why it matters for CSA: Awareness of indicators, breakdowns, and widgets is valuable.
Example: Create a KPI for 'Mean Time to Resolve' with daily snapshots.
Exam Trap ⚠️: Reports run in a user context—permissions affect visible data; set “Run as” carefully.
137
Dashboard — Reporting/Analytics
A collection of widgets/reports providing role‑based insights.
Why it matters for CSA: Key for managers and executives.
Example: Publish a Service Desk dashboard with SLAs, backlog, and aging.
Exam Trap ⚠️: Reports run in a user context—permissions affect visible data; set “Run as” carefully.
138
Indicator — Reporting/Analytics
A PA metric that tracks a specific value over time.
Why it matters for CSA: Defines measurable outcomes.
Example: Indicator: Number of P1 incidents per week.
Exam Trap ⚠️: Reports run in a user context—permissions affect visible data; set “Run as” carefully.
139
Breakdown — Reporting/Analytics
PA grouping dimension (e.g., by assignment group or priority).
Why it matters for CSA: Enables drill‑downs.
Example: Add a breakdown by CI class to the Incident backlog indicator.
Exam Trap ⚠️: Reports run in a user context—permissions affect visible data; set “Run as” carefully.
140
Widget — Reporting/Analytics
Visual component on a dashboard showing a report or PA visualization.
Why it matters for CSA: Aids information delivery.
Example: Add a trend widget for SLA breaches over 90 days.
Exam Trap ⚠️: Reports run in a user context—permissions affect visible data; set “Run as” carefully.
141
ACL Script — Security/Access
A script condition in an ACL that returns true to grant access.
Why it matters for CSA: Critical for complex authorization logic.
Example: Use gs.getUser().isMemberOf('managers') to gate write access.
Exam Trap ⚠️: Do not forget field ACLs—they can block access even if table ACL allows it.
142
Condition Builder — UI/UX
UI for building logical conditions across the platform.
Why it matters for CSA: Appears in reporting, SLAs, notifications.
Example: Build 'Opened this week AND Priority is 1 or 2' list filter.
Exam Trap ⚠️: Personalize affects only you; Configure changes system-wide—avoid unintended global changes.
143
Service Portal — UI/UX
Modern end‑user portal framework with widgets and pages.
Why it matters for CSA: CSA includes portal basics.
Example: Add a Catalog Search widget and customize homepage for IT requests.
Exam Trap ⚠️: Personalize affects only you; Configure changes system-wide—avoid unintended global changes.
144
Widget (Portal) — UI/UX
Reusable AngularJS‑based component in Service Portal rendering UI and logic.
Why it matters for CSA: Awareness helps with portal customization.
Example: Configure the Ticket Tiles widget to show My Incidents and Requests.
Exam Trap ⚠️: Personalize affects only you; Configure changes system-wide—avoid unintended global changes.
145
Catalog Builder — Platform
Guided authoring tool to create and manage catalog items.
Why it matters for CSA: Speeds delivery and standardization.
Example: Use Catalog Builder to create an access request with approval policy.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
146
Record Watcher — Platform
Mechanism to detect data changes for realtime updates or notifications.
Why it matters for CSA: Supports live UX and integrations.
Example: Use Record Watcher to update an agent workspace list when state changes.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
147
Agent Workspace — UI/UX
A modern, configurable workspace for agents with playbooks and contextual info.
Why it matters for CSA: CSA awareness improves UI choices.
Example: Handle an incident in Agent Workspace using a playbook for triage.
Exam Trap ⚠️: Personalize affects only you; Configure changes system-wide—avoid unintended global changes.
148
Playbook — UI/UX
Guided step sequences in Agent Workspace to standardize handling of records.
Why it matters for CSA: Drives consistency and training.
Example: Create a Major Incident playbook with comms and escalation steps.
Exam Trap ⚠️: Personalize affects only you; Configure changes system-wide—avoid unintended global changes.
149
Now Experience UI Builder — UI/UX
Low‑code designer for workspaces and portals using components.
Why it matters for CSA: Modern UI development path to know.
Example: Build a custom page to show Incident KPIs and quick actions.
Exam Trap ⚠️: Personalize affects only you; Configure changes system-wide—avoid unintended global changes.
150
Reference Qualifier — Platform
Rule that filters selectable records in a reference field.
Why it matters for CSA: Prevents bad data selection.
Example: Restrict CI reference to those owned by the caller's department.
Exam Trap ⚠️: Advanced (scripted) qualifiers can be expensive—prefer simple conditions and cache where possible.
151
Normalization — Platform
Standardizing values (e.g., vendor names) for consistency.
Why it matters for CSA: Improves data quality and reporting.
Example: Normalize manufacturer names ingested from asset feeds.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
152
Duplicate Detection — Platform
Finding and merging duplicate records.
Why it matters for CSA: Keeps CMDB and user tables clean.
Example: Run duplicate CI detection rules before reconciling imports.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
153
Business Service Map — Platform
Visualization of a business service and its dependent CIs.
Why it matters for CSA: Supports impact analysis.
Example: Use maps to assess change risk before scheduling.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
154
Task SLA (Record) — ITSM/Process
Task SLA records that track adherence to SLAs per task instance.
Why it matters for CSA: Understanding SLA engine is CSA relevant.
Example: Review Task SLA timers on an Incident to see pause/resume.
Exam Trap ⚠️: Task SLA is a record per task; SLA Definition holds logic/targets—do not confuse record vs definition.
155
SLA Definition — ITSM/Process
Configuration that describes conditions, schedule, and targets for SLA tracking.
Why it matters for CSA: Core configuration element for service commitments.
Example: Set 'Start condition: State = New', Target = 4 hours, Schedule = Business hours.
Exam Trap ⚠️: Task SLA is a record per task; SLA Definition holds logic/targets—do not confuse record vs definition.
156
Schedule — Platform
Defines business hours, holidays, and time zones for SLAs and workflows.
Why it matters for CSA: Accurate schedules affect SLA calculations.
Example: Create a schedule 9–5 Mon–Fri with public holidays for Canberra.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
157
On‑Call Scheduling — ITSM/Process
Manages rosters and escalations for after‑hours support.
Why it matters for CSA: CSA awareness helps incident management.
Example: Page the on‑call Network Engineer for P1 incidents via escalation policy.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
158
Escalation — ITSM/Process
Raising attention or priority due to impact, urgency, or SLA breach.
Why it matters for CSA: Process controls and automation are tested.
Example: Auto‑escalate to duty manager when SLA at 50% of target.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
159
Work Notes — Platform
Internal comments for IT staff recorded on tasks.
Why it matters for CSA: Role‑based visibility is important (often hidden from end users).
Example: Use Work notes for technical diagnostics; keep Additional comments user‑friendly.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
160
Additional Comments — Platform
End‑user visible comments on tasks.
Why it matters for CSA: Controls communications transparency.
Example: Send customer‑friendly updates via Additional comments on the portal.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
161
Attachment — Platform
Files linked to records for evidence or instructions.
Why it matters for CSA: Part of record completeness.
Example: Attach logs and screenshots to incidents for faster triage.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
162
Tagging — Platform
User‑assigned labels that help categorize and find records.
Why it matters for CSA: Improves collaboration and search.
Example: Tag incidents as '#network' for quick filtering.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
163
Activity Formatter — UI/UX
Shows the activity stream (comments, work notes, state changes) on forms.
Why it matters for CSA: Core to collaboration.
Example: Ensure the Activity formatter is on Incident forms for timeline.
Exam Trap ⚠️: Personalize affects only you; Configure changes system-wide—avoid unintended global changes.
164
Number Maintenance — Platform
Controls auto‑number formats and sequences for records (e.g., INC0001234).
Why it matters for CSA: CSA should know number patterns and prefixes.
Example: Set Change numbers to CHG000###### format.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
165
UI Policy Action — UI/UX
The specific change (mandatory, visible, read‑only) made by a UI Policy.
Why it matters for CSA: Granular control on forms.
Example: Add a UI Policy Action to make 'CI' field read‑only when state is Closed.
Exam Trap ⚠️: Personalize affects only you; Configure changes system-wide—avoid unintended global changes.
166
Client Callable Script Include — Platform
Script Include accessible from client scripts via GlideAjax.
Why it matters for CSA: Bridges client/server logic.
Example: Mark 'Client callable' and expose a method returning user department.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
167
Query Business Rule — Platform
Business rule that runs on query to filter results or enforce conditions.
Why it matters for CSA: Affects read access and performance.
Example: Filter out retired CIs from default lists with a query BR.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
168
Display Business Rule — Platform
Business rule that runs before a record is displayed to a user, often to prepare data.
Why it matters for CSA: Used to pass data to client scripts.
Example: Populate g_scratchpad variables for form client logic.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
169
g_form — Platform
Client‑side API object to manipulate form fields and UI.
Why it matters for CSA: Frequently used in client scripts and UI policies.
Example: g_form.setMandatory('close_notes', true) when resolving incident.
Exam Trap ⚠️: g_form only works in client scripts/UI policies on forms—not in server-side scripts.
170
g_scratchpad — Platform
Object used to pass server‑computed data to the client on form load.
Why it matters for CSA: Key to efficient client scripting.
Example: Set g_scratchpad.isManager in a display BR to drive UI visibility.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
171
GlideSystem (gs) — Platform
Server‑side API for logging, messaging, and user/session info.
Why it matters for CSA: Used in many server scripts.
Example: gs.addInfoMessage('Record created successfully');
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
172
Scoped Glide APIs — Platform
API variants limited to scoped apps for security.
Why it matters for CSA: Understanding API differences prevents errors.
Example: Use sn_ws.RESTMessageV2 in scoped apps for outbound REST.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
173
RESTMessageV2 — Integration
API used to define and call outbound REST messages.
Why it matters for CSA: Core for integrations.
Example: Call external HR system to create a user via RESTMessageV2.
Exam Trap ⚠️: RESTMessageV2 is outbound; Scripted REST API is inbound—don’t confuse the two in integrations.
174
Scripted REST API — Integration
Custom REST endpoints defined in ServiceNow using scripts.
Why it matters for CSA: Flexible integration pattern.
Example: Create endpoint /api/x_app/v1/incidents to return filtered data.
Exam Trap ⚠️: Avoid hard-coding credentials—use connection & credential aliases and test with limited data.
175
ACL Condition vs Script — Security/Access
ACLs can grant access via conditions or via scripted logic; both must evaluate true if present.
Why it matters for CSA: Designing minimal scripts is best practice.
Example: Use simple role condition before adding complex script checks.
Exam Trap ⚠️: Do not forget field ACLs—they can block access even if table ACL allows it.
176
Service Graph — Platform
Enhanced CMDB framework for service modeling and integrations with a standardized data model.
Why it matters for CSA: Supports data quality and interoperability.
Example: Adopt Service Graph Connectors for SaaS app ingestion.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
177
Service Graph Connector — Integration
Pre‑built integrations that load third‑party data into CMDB following Service Graph standards.
Why it matters for CSA: Accelerates high‑quality CMDB population.
Example: Use the Azure connector to import VM metadata with relationships.
Exam Trap ⚠️: Avoid hard-coding credentials—use connection & credential aliases and test with limited data.
178
Platform Encryption — Security/Access
Server‑side encryption of data at rest with key management options.
Why it matters for CSA: Protects sensitive data and supports compliance.
Example: Enable encryption on financial fields with key rotation schedule.
Exam Trap ⚠️: Check role, condition, and script—all must evaluate to true; watch Admin override settings.
179
Audit — Security/Access
Records changes to field values over time for traceability.
Why it matters for CSA: Important for governance and troubleshooting.
Example: Enable audit on Priority and Assignment group fields for Incident.
Exam Trap ⚠️: Check role, condition, and script—all must evaluate to true; watch Admin override settings.
180
History Set — Platform
A snapshot of records or configurations at a point in time.
Why it matters for CSA: Useful for comparing before/after states.
Example: Create a history set to compare changes post‑upgrade.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
181
Clone — Platform
Copy of data and configurations from one instance to another.
Why it matters for CSA: CSA covers clone prep and post‑clone tasks.
Example: Clone prod to sub‑prod; exclude sensitive tables via clone profile.
Exam Trap ⚠️: Clones overwrite target data—exclude sensitive tables via clone profile and reconfigure integrations after clone.
182
Clone Profile — Platform
Configuration that defines which tables and data to include/exclude during clone.
Why it matters for CSA: Protects privacy and reduces size.
Example: Exclude audit and email tables during clone to dev.
Exam Trap ⚠️: Clones overwrite target data—exclude sensitive tables via clone profile and reconfigure integrations after clone.
183
Upgrade Monitor — Platform
Tooling to track upgrade progress, conflicts, and skipped records.
Why it matters for CSA: Vital during family upgrades.
Example: Resolve 'Skipped Records' by reviewing compare and deciding keep/update.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
184
Skipped Record — Platform
A customized record not overridden during upgrade to preserve customer changes.
Why it matters for CSA: Must be reviewed post‑upgrade.
Example: Use the Compare UI to accept new version or keep customization.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
185
Fix Script — Platform
Script artifact used to apply data or configuration fixes, typically one‑time.
Why it matters for CSA: Useful during deployments and upgrades.
Example: Run a fix script to initialize a new field across existing records.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
186
Scripted Filter — Platform
A filter using encoded query or scripts to dynamically filter data.
Why it matters for CSA: Powerful for complex list/report logic.
Example: Use addEncodedQuery in a GlideRecord to filter by dynamic date ranges.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
187
Encoded Query — Platform
Compact string representation of a query (e.g., priority=1^ORpriority=2^active=true).
Why it matters for CSA: Essential for scripting and advanced filters.
Example: Save an encoded query for 'P1 or P2 open incidents in last 7 days'.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
188
Reference Cascade — Platform
Behavior where deleting a parent may affect children via reference actions.
Why it matters for CSA: Prevents orphan records.
Example: Set reference action to 'Delete' on child records when parent is removed.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
189
Business Calendar — Platform
Calendar with business schedules used by SLAs and reports.
Why it matters for CSA: Ensures accurate KPI calculations.
Example: Assign business calendar to SLA definition for local holidays.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
190
Time Worked — Platform
Mechanism to track effort spent on tasks.
Why it matters for CSA: Supports costing and productivity metrics.
Example: Enable Time Worked to track resolution effort on major incidents.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
191
Knowledge Workflow — Platform
Approval and publishing process for knowledge articles.
Why it matters for CSA: Governance of knowledge quality.
Example: Require technical review and knowledge manager approval before publish.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
192
Categorization — ITSM/Process
Classification of records via category and subcategory to aid routing and reporting.
Why it matters for CSA: Quality categorization improves analytics.
Example: Define Service, Category, Subcategory taxonomies for Incident.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
193
Configuration vs Customization — Platform
Configuration uses OOTB tools; customization uses code altering default behavior.
Why it matters for CSA: CSA emphasizes minimizing customization for upgradeability.
Example: Prefer UI Policies over client scripts when possible.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
194
Best Practice (Out‑of‑the‑Box) (OOTB) — Platform
Default functionality provided by ServiceNow.
Why it matters for CSA: Understanding OOTB helps avoid unnecessary changes.
Example: Adopt OOTB Incident states unless a strong business case exists.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
195
Scoped Application — Platform
An application with its own scope prefix, artifacts, and access constraints.
Why it matters for CSA: Supports modular, secure development.
Example: Create 'x_company_case_mgmt' app with tables and flows.
Exam Trap ⚠️: Cross-scope access is restricted—APIs differ; ensure you are in the correct scope and update set.
196
Form Sections — UI/UX
Logical groupings of fields on forms to improve usability.
Why it matters for CSA: Form organization is a CSA UI topic.
Example: Add 'Business Impact' section to top of Incident form.
Exam Trap ⚠️: Personalize affects only you; Configure changes system-wide—avoid unintended global changes.
197
Homepage (Legacy) — UI/UX
Classic landing pages with gauges (legacy).
Why it matters for CSA: Awareness helps when supporting older implementations.
Example: Migrate legacy homepages to Dashboards/Workspaces.
Exam Trap ⚠️: Personalize affects only you; Configure changes system-wide—avoid unintended global changes.
198
Gauge (Legacy) — Reporting/Analytics
Legacy mini‑report widget used on homepages.
Why it matters for CSA: Legacy awareness only.
Example: Replace gauges with modern dashboard widgets.
Exam Trap ⚠️: Reports run in a user context—permissions affect visible data; set “Run as” carefully.
199
List Collector — UI/UX
Variable type allowing selection of multiple records from a list.
Why it matters for CSA: Common in catalog design.
Example: Use list collector to choose multiple software titles in a request.
Exam Trap ⚠️: Personalize affects only you; Configure changes system-wide—avoid unintended global changes.
200
Order — UI/UX
Priority value controlling the sequence of UI policies, UI actions, or items.
Why it matters for CSA: Order affects evaluation and display.
Example: Set UI Policy order to run before conflicting policies.
Exam Trap ⚠️: Personalize affects only you; Configure changes system-wide—avoid unintended global changes.
201
Service Level Breach — ITSM/Process
When an SLA target is not met for a task.
Why it matters for CSA: Key KPI and alert trigger.
Example: Trigger escalation and problem creation when breach occurs repeatedly.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
202
Knowledge Feedback — Platform
Mechanism for users to rate or comment on knowledge articles.
Why it matters for CSA: Improves content quality.
Example: Monitor low‑rated articles and flag for revision.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
203
Search Source — Platform
Configuration that defines which tables and fields are indexed and searchable.
Why it matters for CSA: Improves findability and performance.
Example: Add Knowledge articles and catalog items to global search sources.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
204
ACL Debug — Security/Access
Debug mode that logs evaluated ACLs and outcomes.
Why it matters for CSA: Speeds troubleshooting of access issues.
Example: Turn on security debugging to find a deny at field level.
Exam Trap ⚠️: Do not forget field ACLs—they can block access even if table ACL allows it.
205
Access Controls (CRUD) (CRUD) — Security/Access
Create, Read, Update, Delete permissions controlled by ACLs.
Why it matters for CSA: CRUD concepts are foundational.
Example: Grant read only to non‑ITIL roles on Incident via ACLs.
Exam Trap ⚠️: Check role, condition, and script—all must evaluate to true; watch Admin override settings.
206
Transform Script — Platform
Script on a transform map for onBefore/onAfter/onComplete logic.
Why it matters for CSA: Used to cleanse or enrich imported data.
Example: Set department based on email domain during import.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
207
Business Rule Execution Order — Platform
Execution sequence: before, after, async, and order numbers.
Why it matters for CSA: Prevents unexpected outcomes.
Example: Place validation in 'before' and notifications in 'after' BRs.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
208
Async Business Rule — Platform
Runs after database commit in a separate thread.
Why it matters for CSA: Improves performance for non‑critical work.
Example: Send notifications asynchronously to avoid slowing form save.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
209
Reference Qualifier (Advanced) — Platform
Scripted qualifier providing dynamic filtering for reference fields.
Why it matters for CSA: Powerful for context‑aware selections.
Example: Only show CIs where owner = current user.
Exam Trap ⚠️: Advanced (scripted) qualifiers can be expensive—prefer simple conditions and cache where possible.
210
Catalog UI Policy — UI/UX
UI policy applied on catalog item forms in portal or Service Catalog.
Why it matters for CSA: Different from standard UI Policies.
Example: Hide advanced software options unless requester is in Engineering group.
Exam Trap ⚠️: Personalize affects only you; Configure changes system-wide—avoid unintended global changes.
211
Catalog Client Script — Platform
Client script used on catalog item or record producer forms.
Why it matters for CSA: Handles dynamic catalog behaviors.
Example: Auto‑populate manager based on user profile in a request.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
212
Requested For — Platform
Person who will receive the requested item/service.
Why it matters for CSA: Impacts approvals and notifications.
Example: Default Requested for to caller; allow change for proxy requests.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
213
Requested By — Platform
Person who submits the request.
Why it matters for CSA: Audit and communication role.
Example: Use Requested by for approvals and visibility on REQ.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
214
Approval Policy — Platform
Reusable rule defining who must approve certain requests or changes.
Why it matters for CSA: Promotes consistency.
Example: Require manager approval for requests over $500.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
215
Cost (Catalog) — Platform
Pricing or cost information associated with catalog items.
Why it matters for CSA: Useful for chargeback/showback.
Example: Display monthly cost for SaaS subscriptions in the catalog.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
216
sys_id — Platform
Unique 32-character identifier for records used to reference and relate data.
Why it matters for CSA: Commonly used in URLs, scripts, and integrations to uniquely identify records.
Example: Use sys_id to construct a deep link to a specific Incident or to update a record via REST.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
217
ServiceNow Store — Platform
Marketplace for certified applications, spokes, and solutions for ServiceNow.
Why it matters for CSA: Used to install and update apps/spokes; check compatibility during upgrades.
Example: Review Store app compatibility before upgrading to a new release family.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
218
Scope Picker — Platform
Header control that switches the current application scope for development.
Why it matters for CSA: Ensures changes are made in the correct scope and captured in the right update set.
Example: Use the Scope Picker to switch into a scoped app before creating tables and scripts.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
219
sys_dictionary — Platform
System table that stores definitions and attributes for all tables and fields.
Why it matters for CSA: CSA tests where field properties are configured.
Example: Edit a dictionary entry to make a field mandatory.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
220
sys_choice — Platform
Table that stores selectable values for choice fields.
Why it matters for CSA: Choice behavior is commonly tested.
Example: Add a new Priority choice via sys_choice.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
221
Table Extension Hierarchy — Platform
Parent-child relationship where tables inherit fields and behavior.
Why it matters for CSA: CSA often tests which tables extend Task.
Example: Incident extends Task.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
222
Application Navigator — UI/UX
Left-hand navigation used to access applications and modules.
Why it matters for CSA: CSA tests navigation basics.
Example: Filter navigator to find Incident modules.
Exam Trap ⚠️: Personalize affects only you; Configure changes system-wide—avoid unintended global changes.
223
Favorites — UI/UX
User-specific bookmarks for quick access.
Why it matters for CSA: Tests personalize vs configure knowledge.
Example: Star Incident to add to favorites.
Exam Trap ⚠️: Personalize affects only you; Configure changes system-wide—avoid unintended global changes.
224
Context Menu — UI/UX
Right-click menu on lists.
Why it matters for CSA: CSA includes list controls.
Example: Right-click column to configure list.
Exam Trap ⚠️: Personalize affects only you; Configure changes system-wide—avoid unintended global changes.
225
Table ACL — Security/Access
ACL controlling table-level CRUD access.
Why it matters for CSA: CSA tests table vs field ACLs.
Example: Create read ACL on Incident.
Exam Trap ⚠️: Check role, condition, and script—all must evaluate to true; watch Admin override settings.
226
Field ACL — Security/Access
ACL controlling field-level access.
Why it matters for CSA: Field ACLs override table ACLs.
Example: Hide Work notes from users.
Exam Trap ⚠️: Check role, condition, and script—all must evaluate to true; watch Admin override settings.
227
Requires role — Security/Access
Table setting that blocks access without a role.
Why it matters for CSA: Common CSA security question.
Example: Enable Requires role on Incident.
Exam Trap ⚠️: Check role, condition, and script—all must evaluate to true; watch Admin override settings.
228
Admin Override — Security/Access
Allows admins to bypass ACL restrictions.
Why it matters for CSA: CSA tests override behavior.
Example: Disable admin override to enforce ACLs.
Exam Trap ⚠️: Check role, condition, and script—all must evaluate to true; watch Admin override settings.
229
Before Business Rule — Platform
Runs before record is saved.
Why it matters for CSA: CSA tests BR timing.
Example: Set priority before save.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
230
After Business Rule — Platform
Runs after record is saved.
Why it matters for CSA: Tests BR order understanding.
Example: Send notification after update.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
231
Async Business Rule — Platform
Runs asynchronously after commit.
Why it matters for CSA: CSA tests performance considerations.
Example: Send emails async.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
232
Data Policy Rule — Platform
Server-side enforcement rule.
Why it matters for CSA: CSA tests UI vs Data Policy.
Example: Make fields mandatory on import.
Exam Trap ⚠️: Do not confuse Data Policies with UI Policies—Data Policies apply on server side across all entry points.
233
Run as User — Reporting/Analytics
Determines user context for reports.
Why it matters for CSA: Explains report visibility questions.
Example: Run report as admin.
Exam Trap ⚠️: Reports run in a user context—permissions affect visible data; set “Run as” carefully.
234
Scheduled Report — Reporting/Analytics
Report sent on a schedule.
Why it matters for CSA: CSA tests report delivery.
Example: Email weekly Incident backlog.
Exam Trap ⚠️: Reports run in a user context—permissions affect visible data; set “Run as” carefully.
235
Variable Set — Platform
Reusable group of catalog variables.
Why it matters for CSA: CSA tests catalog reuse.
Example: Share requester details across items.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
236
Catalog Task Flow — Platform
Flow automating catalog fulfillment.
Why it matters for CSA: CSA assumes Flow Designer usage.
Example: Auto-create tasks on request.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
237
Incident State Model — ITSM/Process
Standard lifecycle states of an Incident.
Why it matters for CSA: CSA tests OOTB states.
Example: New to Closed.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
238
Standard Change — ITSM/Process
Low-risk pre-approved change.
Why it matters for CSA: CSA tests change types.
Example: Routine patching.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
239
HI Portal (HI) — Platform
ServiceNow customer support portal.
Why it matters for CSA: CSA tests where to log cases.
Example: Check upgrade status.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
240
System Properties — Platform
Key-value settings controlling behavior.
Why it matters for CSA: CSA tests configuration without code.
Example: Enable attachments via property.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
241
ACL — Security/Access
Access Control List rule that grants or denies access to table/field/record operations based on roles, conditions, and scripts.
Why it matters for CSA: Security fundamentals are central to CSA.
Example: Create a table‑level read ACL for Incident that requires the itil role and department match.
Exam Trap ⚠️: Do not forget field ACLs—they can block access even if table ACL allows it.
242
ACL Evaluation Order — Security/Access
ACLs evaluate from most specific to least; all matching rules must grant access for operation to be allowed.
Why it matters for CSA: Understanding order prevents misconfigurations.
Example: Ensure field‑level ACL doesn't block access granted at table level.
Exam Trap ⚠️: All matching ACLs must grant access; evaluation goes most specific to least specific.
243
ACL Types — Security/Access
Table ACLs govern create, read, write, delete; field ACLs govern field‑level operations; and 'record' ACLs target specific records.
Why it matters for CSA: Granularity of access is an exam theme.
Example: Create a field read ACL to hide 'Work notes' from non‑ITIL roles.
Exam Trap ⚠️: Do not forget field ACLs—they can block access even if table ACL allows it.
244
Access Controls (CRUD) (CRUD) — Security/Access
Create, Read, Update, Delete permissions controlled by ACLs.
Why it matters for CSA: CRUD concepts are foundational.
Example: Grant read only to non‑ITIL roles on Incident via ACLs.
Exam Trap ⚠️: Check role, condition, and script—all must evaluate to true; watch Admin override settings.
245
Role Inheritance — Security/Access
Roles can contain other roles, granting cumulative permissions.
Why it matters for CSA: Explains why users gain access indirectly.
Example: itil_admin includes itil; assignment of parent grants child implicitly.
Exam Trap ⚠️: Check role, condition, and script—all must evaluate to true; watch Admin override settings.
246
Impersonation Testing — Security/Access
Verifying UI and data access by impersonating target roles.
Why it matters for CSA: Ensures correct access controls.
Example: Impersonate a requester to verify portal sees only their incidents.
Exam Trap ⚠️: Check role, condition, and script—all must evaluate to true; watch Admin override settings.
247
Update Set — Platform
A container that captures configuration changes for moving between instances.
Why it matters for CSA: Critical for promoting changes across dev/test/prod—high CSA relevance.
Example: Record changes in an update set, complete it, export XML, and import to test/prod.
Exam Trap ⚠️: Update Sets capture configuration, not data—preview for collisions before commit; never move records like Incidents.
248
Preview/Commit — Platform
Steps to validate (preview) and apply (commit) update set changes on a target instance.
Why it matters for CSA: Knowledge of collisions and resolution is tested.
Example: Preview shows collisions; resolve then commit to apply changes safely.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
249
Collision — Platform
A conflict during update set preview when a target has changes that differ from incoming updates.
Why it matters for CSA: CSA covers identifying and resolving collisions.
Example: Use the Compare UI to merge or back out overlapping dictionary updates.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
250
Update Set Preview Problems — Platform
Issues detected during update set preview such as missing dependencies or collisions.
Why it matters for CSA: Critical to safe promotions.
Example: Resolve missing table dependency before committing the update set.
Exam Trap ⚠️: Update Sets capture configuration, not data—preview for collisions before commit; never move records like Incidents.
251
Scoped vs. Global — Platform
Global scope allows cross-app access; scoped apps encapsulate artifacts and restrict access.
Why it matters for CSA: Affects security and script access.
Example: Build customizations in scoped apps to avoid collisions with global artifacts.
Exam Trap ⚠️: Cross-scope access is restricted—APIs differ; ensure you are in the correct scope and update set.
252
Application Scope — Platform
Defines the namespace and boundaries for an app, controlling which artifacts are accessible and which scripts can call others.
Why it matters for CSA: Scope affects update set behavior, script include access, and security—key CSA knowledge.
Example: Create a scoped app to encapsulate custom tables and script includes, limiting cross‑app access.
Exam Trap ⚠️: Cross-scope access is restricted—APIs differ; ensure you are in the correct scope and update set.
253
Flow Designer — Platform
No‑code/low‑code automation designer replacing many legacy workflows.
Why it matters for CSA: CSA includes creating flows, actions, subflows, and triggers.
Example: Build a flow that triggers on Incident creation to assign and notify based on category.
Exam Trap ⚠️: Avoid mixing legacy Workflow with Flow Designer artifacts—choose one approach per process.
254
Subflow — Platform
A reusable Flow Designer component called from flows or other subflows.
Why it matters for CSA: Encouraged for modularity and reuse.
Example: Create a subflow 'Notify Assignment Group' used by multiple task flows.
Exam Trap ⚠️: Avoid mixing legacy Workflow with Flow Designer artifacts—choose one approach per process.
255
Action (Flow Designer) — Platform
A step in Flow Designer that performs a function, either out-of-box or custom-built.
Why it matters for CSA: Key to building maintainable automations.
Example: Use the 'Create Record' action to open a Problem from a P1 Incident.
Exam Trap ⚠️: Avoid mixing legacy Workflow with Flow Designer artifacts—choose one approach per process.
256
Service Catalog — Platform
A curated list of services and items end users can request via the portal.
Why it matters for CSA: CSA covers catalog items, variables, workflows, and request fulfillment.
Example: Create a catalog item 'Request Laptop' with variables, approvals, and task fulfillment.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
257
Catalog Item — Platform
An orderable item in the Service Catalog with variables and fulfillment.
Why it matters for CSA: Core to self‑service automation topics.
Example: Build a catalog item that provisions a mailbox via IntegrationHub.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
258
Record Producer — Platform
A catalog item that creates a record in any table using user‑friendly questions.
Why it matters for CSA: Important for simplifying data capture.
Example: Use a record producer to submit an Incident from the portal with tailored questions.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
259
CMDB — Platform
Configuration Management Database storing CIs and relationships to support ITSM processes.
Why it matters for CSA: CSA includes CMDB structure and data quality.
Example: Use the CMDB CI Class Manager to review CI classes and attributes.
Exam Trap ⚠️: CMDB stores configuration items and relationships—not incidents or tasks; use IRE to avoid duplicates.
260
CI — Platform
Configuration Item—an asset, service component, or logical entity tracked in the CMDB.
Why it matters for CSA: CIs underpin Incident, Problem, and Change processes.
Example: Link an Incident to the affected CI to enable impact analysis and outage tracking.
Exam Trap ⚠️: CMDB stores configuration items and relationships—not incidents or tasks; use IRE to avoid duplicates.
261
Identification & Reconciliation — Platform
Processes ensuring unique CI records and authoritative sources win in data conflicts.
Why it matters for CSA: Critical to maintain CMDB integrity.
Example: Configure IRE to prefer Discovery for hardware attributes over imports.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
262
SLA Definition — ITSM/Process
Configuration that describes conditions, schedule, and targets for SLA tracking.
Why it matters for CSA: Core configuration element for service commitments.
Example: Set 'Start condition: State = New', Target = 4 hours, Schedule = Business hours.
Exam Trap ⚠️: Task SLA is a record per task; SLA Definition holds logic/targets—do not confuse record vs definition.
263
Task SLA (Record) — ITSM/Process
Task SLA records that track adherence to SLAs per task instance.
Why it matters for CSA: Understanding SLA engine is CSA relevant.
Example: Review Task SLA timers on an Incident to see pause/resume.
Exam Trap ⚠️: Task SLA is a record per task; SLA Definition holds logic/targets—do not confuse record vs definition.
264
Data Policy vs UI Policy — Platform
UI Policies affect forms in browser; Data Policies enforce rules at server‑side for all entry points.
Why it matters for CSA: CSA comparative knowledge.
Example: Use Data Policy to ensure mandatory fields are enforced on imports.
Exam Trap ⚠️: UI Policies affect forms only; Data Policies enforce rules on all entry points (imports, integrations, API).
265
g_form — Platform
Client‑side API object to manipulate form fields and UI.
Why it matters for CSA: Frequently used in client scripts and UI policies.
Example: g_form.setMandatory('close_notes', true) when resolving incident.
Exam Trap ⚠️: g_form only works in client scripts/UI policies on forms—not in server-side scripts.
266
GlideRecord — Platform
Server‑side API for database operations: querying, inserting, updating, and deleting records.
Why it matters for CSA: Core scripting concept on CSA.
Example: Use GlideRecord to query open incidents older than 7 days and notify owners.
Exam Trap ⚠️: GlideRecord runs server-side—use GlideAjax for client-to-server calls; remember to call .next() in loops.
267
GlideAjax — Platform
Client‑to‑server call mechanism to execute server logic from client scripts asynchronously.
Why it matters for CSA: Bridges client and server—key in UI performance.
Example: Use GlideAjax to fetch CI ownership info without reloading the form.
Exam Trap ⚠️: GlideAjax requires a client-callable Script Include; avoid heavy queries on form load.
268
RESTMessageV2 — Integration
API used to define and call outbound REST messages.
Why it matters for CSA: Core for integrations.
Example: Call external HR system to create a user via RESTMessageV2.
Exam Trap ⚠️: RESTMessageV2 is outbound; Scripted REST API is inbound—don’t confuse the two in integrations.
269
Scripted REST API — Integration
Custom REST endpoints defined in ServiceNow using scripts.
Why it matters for CSA: Flexible integration pattern.
Example: Create endpoint /api/x_app/v1/incidents to return filtered data.
Exam Trap ⚠️: Avoid hard-coding credentials—use connection & credential aliases and test with limited data.
270
sys_id — Platform
Unique 32-character identifier for records used to reference and relate data.
Why it matters for CSA: Commonly used in URLs, scripts, and integrations to uniquely identify records.
Example: Use sys_id to construct a deep link to a specific Incident or to update a record via REST.
Exam Trap ⚠️: Know where it is configured and which records it affects—don’t confuse similarly named features.
ServiceNow CSA
flashcards
Decks in class (8)
# Cards
-
Danger Cards33
-
7% Topic 1 – Platform Overview & Navigation48
-
10% Topic 2 – Instance Configuration68
-
20% Topic 3 – Configuring Applications for Collaboration69
-
20% Topic 4 – Self-Service & Automation68
-
30% Topic 5 – Database Management & Platform Security95
-
13% Topic 6 – Data Migration & Integration61
-
CSA Terminologies270
