Section 5.1: CSDM Framework and Foundation Domain

CSDM Framework and Foundation Domain

The Common Service Data Model (CSDM) is a prescriptive, framework-based approach to mapping ServiceNow data. It is crucial to understand that CSDM is not a product, plugin, or single code set. Instead, it is a shared data schema and set of best practices that define how standard tables and relationship types should be utilized across ServiceNow applications such as IT Service Management (ITSM), IT Operations Management (ITOM), IT Asset Management (ITAM), and Application Portfolio Management (APM). By enforcing standard tables and relationship definitions, CSDM enables cross-platform reporting, reduces customization, and ensures that platform upgrades do not break service models.

CSDM Evolution and Versions

The framework has evolved continuously to support broader business capabilities:

• CSDM 1.0: Focused primarily on the ITOM space, defining basic relationships between servers, databases, and application services.
• CSDM 2.0: Shifted focus toward service modeling, introducing the concept of Technical Services and Business Services, along with their respective Sell/Consume and Manage Technical Services domains.
• CSDM 3.0: Introduced the Build domain and formalized the lifecycle status mapping configurations, helping bridge the gap between asset management and configuration management.
• CSDM 4.0: Refined the Build domain by adding the Software Development Lifecycle (SDLC) component and introduced digital product models, aligning the framework with modern cloud-native and agile DevOps environments.

CSDM 4.0 Domain Overview

CSDM 4.0 organizes the ServiceNow platform's data model into five distinct domains. Each domain addresses a specific phase of the product lifecycle or organizational context. The domains are:

The Foundation Domain

The Foundation Domain represents the bed-rock of the CSDM framework. It contains administrative reference data that is non-CI data. It is an exam-critical detail that tables within the Foundation domain do not extend the base configuration item table (cmdb_ci). Therefore, Foundation records are not Configuration Items, but they are referenced by CIs to establish ownership, location, and organizational structure.

The primary tables within this domain include:

• User (sys_user): Represents individual people within the organization.
• Group (sys_user_group): Collections of users. In CSDM, groups are assigned specific roles such as Change Approver, Assignment Group (ITSM routing), Support Group (infrastructure ownership), and Managed By Group.
• Location (cmn_location): Physical addresses or datacenters where infrastructure CIs reside.
• Company (core_company): Internal corporate entities, vendors, or manufacturers.
• Department (cmn_department) and Business Unit (business_unit): Map the internal functional reporting lines.

A critical design requirement in CSDM 4.0 is that all organizational metadata must be clean and consistent. For instance, without accurate location data, Discovery cannot populate datacenter fields, and without clean group records, incident routing to support teams will fail.

Reference fields on the base Configuration Item table (cmdb_ci) link CIs to the Foundation domain. Key fields include:

• Supported by: References a User who handles operations.
• Managed by: References a User who manages the CI configuration.
• Support group: References a Group responsible for incident resolution.
• Assignment group: References a Group that receives automated tasks.
• Location: References a Location record for physical or logical assignment.

Reference Field Mappings to Foundation Data

Every operational CI in the CMDB contains default reference fields that link it to Foundation tables:

• Owned by (owned_by): Points to a sys_user record representing the business owner who is accountable for the CI.
• Support Group (support_group): Points to a sys_user_group responsible for operational support and incident resolution.
• Change Group (change_control): Points to a sys_user_group responsible for approving changes to the CI.
• Location (location): Points to a cmn_location record indicating where the CI is physically or logically situated.

Standard Lifecycle Stage Mappings

Historically, ServiceNow tracked the state of assets and CIs using two distinct fields: install_status (used heavily by Asset Management) and operational_status (used heavily by CMDB and IT Operations). Because these fields were independent, they frequently drifted out of sync, leading to severe discrepancies where an asset was marked as "retired" but its corresponding server CI remained "operational."

To resolve this, CSDM introduced standard Lifecycle Stage Mappings. This framework provides two unified, platform-wide fields:

1. Lifecycle Stage (lifecycle_stage): Represents the high-level phase (e.g., Plan, Build, Operate, Retire, End of Life).
2. Lifecycle Stage Status (lifecycle_stage_status): Provides a granular state within the stage (e.g., under Operate, statuses include Active, In Repair, and Temporarily Unavailable).

ServiceNow provides an activation plugin that installs mapping tables and business rules. When activated, any update to a CI's lifecycle stage automatically synchronizes with the associated asset record's status, ensuring alignment across ITSM, APM, and HAM (Hardware Asset Management). This prevents operational outages caused by monitoring retired servers or purchasing software licenses for active hosts that were mistakenly marked as decommissioned.