The current ServiceNow CSA blueprint can be mapped as one instance lifecycle. Platform navigation establishes orientation; instance configuration shapes the environment; collaboration features expose and organize work; self-service and automation reduce manual effort; database/security controls protect the platform core; migration/integration move configuration and logic between systems or instances. The current CSA weighting is 7/10/20/20/30/13.
The instance is the center of the map
Every CSA task happens inside a ServiceNow instance with applications, tables, users, roles, interfaces, and configuration. Understanding how an instance differs from an application or module prevents navigation concepts from blending with customization concepts.
The platform layer should be mapped before the administrator changes anything.
Navigation leads to the right configuration surface
Next Experience Unified Navigation, modules, lists, forms, and common user interfaces are the entry points to records and settings. Navigation itself is not the business process, but it determines whether the administrator can locate the data and configuration that implement the process.
A good mental map is faster than memorizing isolated menu paths.
Instance configuration controls platform behavior
Applications and plugins add capability; personalization changes a user’s experience; instance configuration changes shared behavior. Administrators should know the difference because the scope of a change determines who is affected.
Upgrade-safe configuration is usually preferable to unnecessary customization.
Lists and forms expose the data model
Lists display record sets, filters reduce them, forms expose one record, references connect tables, and related lists reveal relationships. Forms, views, templates, and attributes change how users interact with the same underlying table.
The objective map should connect UI behavior back to the database schema rather than treating forms as independent pages.
Tasks, boards, dashboards, and notifications organize work
Task-based applications, Visual Task Boards, dashboards, analytics, and notifications make work visible and actionable. These features turn records into operational queues, status, and communication.
An administrator should understand which data drives the visualization or message so dashboards do not become disconnected from the underlying process.
Knowledge and Service Catalog enable self-service
Knowledge articles help users solve known issues, while the Service Catalog lets users request defined products or services. Catalog items can create approvals, tasks, or automation.
A CSA platform map should show self-service reducing routine support work while still creating controlled backend fulfillment.
Workflow Studio and Virtual Agent add automation
Workflow Studio can orchestrate logic around triggers, actions, approvals, and records, while Virtual Agent gives users a conversational path into knowledge and service workflows. The objective is to reduce manual steps without losing governance.
Automation should be observable and maintainable rather than hidden in undocumented scripts.
Database schema and security form the platform core
Tables, extensions, fields, relationships, access controls, roles, data import, CMDB/CSDM, and Security Center all affect the integrity of the instance. This is why the domain carries 30% of the exam.
Security belongs at the data/platform layer where every interface respects the rule.
Business Rules and UI Policies act at different layers
UI Policies change client-side form behavior such as visible, mandatory, or read-only state. Business Rules execute server-side around database operations and can enforce or automate behavior independent of a specific form.
Choosing the right layer avoids logic that works in one interface but fails through imports or integrations.
Update sets and scripting complete the configuration lifecycle
Update sets move supported configuration changes between instances, while scripting provides extension where declarative features are insufficient. The administrator should know what is captured, what needs separate data migration, and how custom code can affect upgrades.
The map should include users, groups, and roles even though they appear across several domains. User identity determines who signs in; group membership organizes work; roles govern capability and access. These identity objects connect collaboration, security, approvals, notifications, and administration.
Application scope should be drawn around custom applications because it defines a boundary for tables, scripts, permissions, and cross-application access. Administrators should recognize that global and scoped applications can behave differently when one component attempts to use another’s resources.
Dictionary entries belong under the schema because field type, default value, reference target, attributes, and other metadata influence every place the field is used. A form change may be local to a view, but a dictionary change can alter behavior platform-wide.
Table extension should connect child records to inherited fields and behavior. When Incident extends Task, shared task fields are not duplicated independently. This inheritance model is important for understanding why reports, business rules, and security can sometimes operate across related task tables.
Reference fields should be shown as relational links between tables. They let a record point to another record such as a caller, assignment group, or configuration item. Good reference design reduces duplicate text and supports consistent reporting or automation.
Import sets should sit between external data and production tables. A transform map controls how source fields become target fields, while coalesce logic helps identify existing records. The map should show staging and validation before data changes the operational table.
CMDB relationships should be drawn as a graph rather than a flat inventory. A server can support an application, depend on a database, or belong to a service. These relationships make impact analysis and service-aware processes possible when the data is accurate.
CSDM belongs above the CMDB as a modeling framework for organizing service information consistently. It helps different teams use common concepts for business applications, technical services, offerings, and supporting infrastructure instead of inventing incompatible structures.
Security Center should sit above ACLs as posture and security-management context. Access controls enforce record/field permissions, while security-management tooling can help administrators identify broader security configuration or risk. The blueprint groups them because platform security is both preventive and operational.
Knowledge articles should connect to search and Virtual Agent because self-service quality depends on findable, current content. An automation or bot that points users to outdated knowledge can scale the wrong answer faster than a human help desk would.
Service Catalog should connect variable input, approvals, flows, fulfillment tasks, and requested-item records. The request portal is only the front end; the real design is the controlled process generated behind it.
Workflow Studio should sit where manual task transitions become repeatable logic. It can call actions, update records, create approvals, or integrate with other services. The map should show automation using platform data and security rather than bypassing them.
Notifications should attach to events or record conditions across the map. A password-reset, approval, task assignment, or knowledge update can all generate communications. Good notification design considers audience, timing, frequency, and sensitive content.
Visualizations and Platform Analytics should sit on the evidence branch. They aggregate operational records into trends, KPIs, and dashboards. Administrators should trace a surprising metric back to the source table/filter before changing the business process.
Update sets should be shown as configuration transport, not a complete migration mechanism. Some data, attachments, or application artifacts may require other methods. The administrator should know what the update set captures and validate the target after commit.
Scripting should remain the outer extension layer. Client scripts, Business Rules, script includes, or other coded components can add flexibility, but the CSA map should always check whether a declarative platform feature solves the requirement more simply and safely first.
Roles should connect both navigation and security because a role can expose modules while also participating in ACL decisions. Seeing a menu item is not proof that every underlying record operation is allowed, and hiding a module is not a substitute for data security.
Form templates should sit on the productivity branch. They can prepopulate field values for recurring record types, reducing manual entry and improving consistency. They do not replace business rules or mandatory controls because users may create records through other paths.
Task management should connect assignment groups, state, priority, SLA-like process concepts, and notifications. The exact business application can vary, but the platform’s Task inheritance gives administrators a common model for work records.
Virtual Agent should connect to both knowledge and catalog automation. A topic can answer an informational question, collect user input, or initiate a request. The quality of the conversational experience depends on the accuracy of content and the reliability of the underlying process.
Shared responsibility should sit outside the instance boundary. ServiceNow operates the SaaS infrastructure and platform according to its responsibilities, while the customer remains responsible for users, roles, data, configuration, integrations, and how applications are used. Security questions often test this boundary.
The complete map also supports troubleshooting: identify the record/table, check access, determine whether behavior is client-side or server-side, inspect automation, review imported/integrated data, and validate configuration transport. This sequence is more reliable than changing forms or scripts at random.
Coalesce should be placed on the import branch because it helps a transform map decide whether incoming data updates an existing record or creates a new one. Poor coalesce design can duplicate users, assets, or configuration items and damage reports long after the import finishes.
Application and Access Control should also connect to integrations. An integration user or service account can be subject to ACLs and scoped permissions just like a human user. Granting broad admin rights to simplify an integration creates unnecessary risk.
One final relationship to keep visible is upgrade safety. Declarative configuration, scoped applications, documented update sets, and limited custom scripting are easier to maintain across platform upgrades than heavily customized global behavior. CSA-level administration should favor supported platform patterns unless the business requirement clearly demands extension.
The full CSA map is navigate → configure → collaborate → self-service/automate → secure data → migrate/integrate. That sequence mirrors the way a ServiceNow administrator operates the platform.