CDM data model

  • Release version: Australia
  • Updated March 12, 2026
  • 9 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of CDM data model

    The CDM (Configuration Data Model) data model in ServiceNow provides a standardized and intuitive data structure to manage the full lifecycle of software delivery, including automation, quality validation, and alignment with CSDM. It allows you to import existing configuration data in formats such as JSON, YAML, INI, and XML, validate it against custom policies, and export validated configuration data into your organization’s DevOps pipeline for application, service, and infrastructure deployment.

    Show full answer Show less

    Note that starting with the Washington D.C. release, the DevOps Config feature is being deprecated but remains supported on existing instances.

    Key Features

    • Hierarchical structure: Configuration data is organized into applications, which contain folders for Components, Collections, and Deployables to represent logical units, release versions, and environment-specific deployments.
    • Components: These are the fundamental building blocks representing config data for logical elements like microservices, servers, or templates. Components can include variables and nested components and can be shared in component libraries to promote consistency across applications.
    • Collections: Collections group components to define a release composition. They may include variables, overrides, and overlays specific to the release version, enabling you to manage different configurations for different releases or feature sets.
    • Deployables: Deployables represent environment-specific configurations (e.g., Development, Test, Production) that combine collections with environment-specific variable and override settings. They link to application or infrastructure services in the CMDB and can be deployed through your CI/CD pipeline.
    • Variables and Overrides: Variables can be defined at component, collection, and deployable levels with precedence rules, enabling flexible reuse and environment-specific customization of config data.
    • Changesets and Snapshots: Changes committed to the CDM application generate changesets and snapshots of affected deployables. Snapshots are validated against policies and, once approved, are exportable as configuration data for deployment.
    • Shared Components and Component Libraries: Facilitate reuse of components across applications with a single source of truth, enhancing maintainability and consistency.
    • File Nodes: You can attach files of supported MIME types to config data models or component libraries for additional contextual data storage.
    • Contextual Variables: Out-of-the-box variables provided by ServiceNow enable dynamic configuration based on the context of a node.

    Practical Application for ServiceNow Customers

    Using the CDM data model enables your organization to:

    • Standardize and version control configuration data systematically across software delivery lifecycles.
    • Encrypt and control access to sensitive configuration information.
    • Automate validation of configuration data to ensure compliance and quality before deployment.
    • Reuse configuration elements efficiently by leveraging variables and overlays, simplifying management across multiple environments and release versions.
    • Integrate configuration data seamlessly into your existing DevOps pipelines for continuous deployment aligned with your CMDB services.

    By adopting CDM, you gain transparent management of configuration data through a structured, policy-driven approach that supports agility and governance in delivering applications and infrastructure.

    The CDM data model is a standardized data structure that supports the broader life cycle of software delivery — automation, quality validation, and CSDM. CDM imports existing config data, validates it using policies that you define, and exports valid config data to your organization's existing DevOps pipeline to implement applications, services, and infrastructure.

    Important:
    Starting with the Washington D.C. release, DevOps Config is being prepared for future deprecation. It will be hidden and no longer activated on new instances but will continue to be supported.

    CDM data model overview

    The CDM data model does not change the way you think about configuration. Rather, you use the CDM REST API and user interface to map your existing JSON, YAML, INI, XML, and other config data into an intuitive data structure that provides the following benefits:
    • Implements rigorous and transparent version and change control.
    • Enables you to encrypt sensitive data and ensures appropriate access control for the data.
    • Enables automated validation of config data.
    • Enables you to reuse config data structures by using variables, including values, and overlaying values.

    Structure of the CDM data model

    An application in CDM is the full collection of config data for an application service, application model, or dynamic CI group [infrastructure] in the CMDB. The CDM user creates an application record that includes the following empty folders in a standard hierarchical structure. After the system ingests your existing config data, you structure the data into components in the appropriate folder. You create collections of the components and then combine the collections into a deployable — a config dataset (for a development, test, or production environment) that can be deployed by your delivery process. Each component, collection, variable, and deployable is a node in the structure.

    Folder structure for a new CDM application

    Components
    Components are the building blocks that typically represent the config data for a logical element of an application or a part of an infrastructure service. For example, a monolithic app, a micro-service, a physical server, or a Docker template.

    A component can include descendent components, either direct or included. A component can include variables that can take on different values in collections and deployables.

    You can group components into a library of shared components.

    Tip:
    It is often useful to define a default value for a variable in a component or collection. This is a powerful strategy because you can create a broad variety of deployables from a small set of components and collections. Deployables that inherit a component or collection can use overrides, overlays, and variable settings to meet the needs of the environment type. For example, the Development deployable can use the same components and collections as the Test deployable. Development uses the default database variable value. Test, in contrast, uses a different value that is appropriate for the test environment.
    Components Vars folder
    The components Vars folder can contain variables that any CDI in the Components folder can use. There is only one components Vars folder.
    Collections

    A collection is the set of components that together define a release — You can think of a collection as a release composition.

    A collection can include variable or override settings that are specific to the particular version. For example, the VM config data used in release-1 is different from the data used in release-2. release-1 might use the value 2Gb for the memory setting ("memory": "2Gb") and release-2 might specify a different value ("memory": "4Gb"). In addition, a collection might include config settings that do not appear in its components. Such values are called overlays.

    A collection might represent a particular version of an application, localization, or feature set. For example, a collection named collection-2 might include the set of components or component versions that represent the Release 2.0 functionality for the application. In contrast, a collection named collection-3 that represents the Release 3.0 functionality might include the same set of components or component versions, additional components or component versions, and other variable, override, and overlay settings.

    Collections Vars folder
    The collection Vars folder can contain variables that any CDI in the Collections folder can use. Each collection has one collection Vars folder. A collection variable has higher precedence than a component variable.
    Deployables

    You add and configure deployables in the data structure. A deployable is a config dataset (for a DEV, TEST, or PROD environment) that can be deployed by your delivery process. Each deployable in an application represents the configuration of a service in the CMDB.

    A deployable is made up of the collection or set of collections that define the release for a particular environment. The combination of collections+environment link to an application service in the CMDB or to an infrastructure service.

    A deployable can include variable or override settings that are specific to the environment. For example, the database variable has one value in the development environment and a different value in the production environment. An override value in the production deployable might specify a required container parameter that is not needed in the development environment.

    An example deployable named DEV-2 would include the collection-2 collection and would specify variable, override, and overlay settings that are specific to the development environment for release 2.0. In contrast, the deployable named PROD-2 would also include the collection-2 collection but, instead, would specify settings that are specific to the production environment for release 2.0.

    When you are happy with a changeset, you can save and commit the changes. The system checks for conflicts with the committed changesets of other users. If there are no conflicts, the system persists the changes and then generates a snapshot of every deployable that is affected by the changes. A snapshot represents a potential exportable config data set. The system validates config data by executing policies against each snapshot and returning the validation results.

    Deployable Vars folder
    The deployable Vars folder can contain variables that any CDI in the Deployables folder can use. Each deployable has one deployable Vars folder. A deployable variable has higher precedence than a collection variable.

    Example

    In the following diagram of the example BookStore application, the numbers identify the relationships among components, collections, and deployables.
    1. Components are grouped to form collections that represent environments or versions of environments. The FS2 (feature set 2) collection has config data for Core version 2 of the application that is currently being developed and tested. FS1, in contrast, holds the earlier Core version 1 that has been thoroughly tested and is currently running the application in the production environment.
    2. In the example, both FS2 (the collection that is used in test environments) and FS1 (the collection that is used in the production environment) use config data for both S3 and a particular VM template. Both the FS1 and FS2 collections, therefore, inherit these two components. Because the collections represent different feature sets, it is probably the case that FS1 and FS2 use variables or overrides to specify a few different settings for the components.
    3. Each deployable includes the collection that is appropriate for its environment (development, test, or production). In the example, the TEST deployable uses the FS2 collection, the newer version of the feature set and other config settings that is used in test environments. The PROD deployable, in contrast, uses FS1 in the production environment. FS1 is the earlier version of the collection of config data that had been validated for production.

      In each deployable, variables are set to values that are appropriate for the environment. For example, in PROD, the database variable is set to prod1 (the production database). The TEST deployable, however, specifies one of the databases that is used by the testing team, test3.

    This diagram is simplified. In your implementation, deployables can include multiple collections, variable and override settings, and overlay settings (settings that do not appear in the components and collections that make up the deployable). In addition, you might have several deployables for each environment type.

    How components and collections supply content that you can build into deployables for a variety of environments

    Definitions

    CDI
    A config data item (CDI) is simple a key-value node.
    Variable
    A variable is a key-value item that can be referenced within a CDI.
    Parent nodes and child (leaf) nodes
    • CDIs and variables are key-value items. CDIs and variables can only be child nodes.
    • Components, collections, deployables, and folders nodes can be parent nodes—nodes that can have key-value items or other parent nodes.
    Note:

    Starting with Configuration Data Management version 4.2, you can define a node using any UTF-8 character, including the forward slash (/).

    Name path
    The name path is the complete folder path of the selected node in the list. In REST API, you can provide name path in array in the following formats:
    • Backslash format: For example - testApp/deployables/Development1/cdi1
      Note:
      If your node name contains a backslash ("/"), you can't use this format.
    • Backend name path with replacement characters: For example - testApp�deployables�Development1�cdi1
    • Array: For example - ['testApp','deployables','Development1','cdi1']
    Components
    Components are the building blocks that typically represent the config data for a logical element of an application or a part of an infrastructure service. For example, a monolithic app, a micro-service, a physical server, or a Docker template.

    A component can contain variables that can take on different values in collections and deployables. More detailed instructions appear in Define or update a component.

    Collections

    A collection is the set of components that together define a release — You can think of a collection as a release composition.

    A collection can contain variable or override settings that are specific to the particular version. For example, the VM config data used in release-1 is different from the data used in release-2. release-1 might use the value 2Gb for the memory setting ("memory": "2Gb") and release-2 might specify a different value ("memory": "4Gb"). In addition, a collection might include config settings that do not appear in its components. You might think of such values as "overlays".

    Deployables

    A deployable is a config dataset (for a development, test, or production environment) that can be deployed into your CI/CD pipeline as a service. Each deployable in an application configures a service in the CMDB. For example, you might create three deployables, one for each environment type: Development, Test, and Production.

    A deployable is made up of the collection or set of collections that define the release for a particular environment. The combination of collections+environment link to an application service in the CMDB or an infrastructure service.

    A deployable can contain variable or override settings that are specific to the environment. For example, the database variable has one value in the development environment and a different value in the production environment. An override value in the production deployable might specify a required container parameter that is not needed in the development environment.

    Changesets and Snapshots
    When you commit changes to a CDM application, the system persists the changes as a changeset of the application. The system then also generates a snapshot of every deployable that is affected by the changes. A snapshot represents a potential exportable config data set. The system validates config data by executing policies against each snapshot and returning the validation results. Snapshots that pass validation and that are published can be exported to the release pipeline as config data.
    Shared components and Component libraries
    Shared components in Configuration Data Management enables you to use a component across several applications.

    For better organization, these shared components are managed in Component libraries. These component libraries improve consistency and maintainability by ensuring a single source of truth for a component's config data across applications.

    File nodes
    A file node is created when you attach a file to the config data model of a CDM app or a component library. It contains a link to the attached file. Using file nodes, you can attach files of any MIME type supported on ServiceNow AI Platform.