---
sourceDocument: Australia IT Service Management
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/it-service-management

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia IT Service Management

ft:clusterId :

    - itsm

bundleId :

    - itsm

workflow :

    - Technology


---

# CDM data model

# CDM data model {#ariaid-title1}

Release version: Australia  
Updated March 12, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 9 minutes to read  
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 {#cdm-data-model__section_qj4_nzk_n4b}

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.
{#cdm-data-model__ul_y5y_nzk_n4b}

## Structure of the CDM data
model {#cdm-data-model__section_s5w_ss2_vpb}

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 <kbd class="ph userinput">Development</kbd> deployable can use the same components and collections as the <kbd class="ph userinput">Test</kbd> deployable. <kbd class="ph userinput">Development</kbd> uses the default <var class="keyword varname">database</var> variable value. <kbd class="ph userinput">Test</kbd>, 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 <var class="keyword varname">memory</var> 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 <kbd class="ph userinput">collection-2</kbd> might
    include the set of components or component versions that represent the
    <kbd class="ph userinput">Release 2.0</kbd> functionality for the application. In contrast, a
    collection named <kbd class="ph userinput">collection-3</kbd> that represents the
    <kbd class="ph userinput">Release 3.0</kbd> 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 <kbd class="ph userinput">DEV-2</kbd> would include the
    <kbd class="ph userinput">collection-2</kbd> 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
    <kbd class="ph userinput">PROD-2</kbd> would also include the
    <kbd class="ph userinput">collection-2</kbd> 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 {#cdm-data-model__section_d5m_5vd_jqb}

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 <var class="keyword varname">database</var> variable is set to <kbd class="ph userinput">prod1</kbd> (the
   production database). The TEST deployable, however, specifies one of the databases that is used by the testing team, <kbd class="ph userinput">test3</kbd>.

{#cdm-data-model__ol_k44_g3s_2qb}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.

## Definitions {#cdm-data-model__section_ctr_qvr_5sb}

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.

    {#cdm-data-model__ul_ngk_fwr_5sb}  
    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'\]
    {#cdm-data-model__ul_ezj_zbg_cyb}

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](https://servicenow-prod.fluidtopics.net/BKH7Lv5UIFJS3sHhuxgAEQ "Define or update a component while working in a changeset.").

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 <var class="keyword varname">memory</var> 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.
* **[Contextual variables for config data](https://servicenow-prod.fluidtopics.net/AryjbgWUlWTu95hfxXl7dg)**   
  Contextual variables are out-of-the-box variables delivered by ServiceNow that enable you to use the context of a node to define a variable.

**Related concepts**   

* [Preparing an application for config data upload](https://servicenow-prod.fluidtopics.net/8Q5kClfh4tg6NVjQaKuLmw "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. After you upload your source config data, the application can support all potential deployables that make up each version of the development, test, and production environments of the service.")  
**Related tasks**   

* [Create and update a deployable](https://servicenow-prod.fluidtopics.net/ay6idNbQQGyQa475bBEnqA "Create a deployable while working in a changeset. You can add multiple components and collections to a deployable.")