---
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
---
# Preparing an application for config data upload
# Preparing an application for config data upload {#ariaid-title1}
Release version: Australia
Updated March 12, 2026
 4 minutes to read
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.
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.
## Overview: Preparing an application to accept uploaded config data {#cdm-prep-app-for-upload__section_kct_wt2_44b}
You follow this general process to prepare an application to accept the upload of config data:
1. On the Apps tab, you, a user with the CDM Admin \[sn_cdm.cdm_admin\] role, create an application record.
The system generates an application that includes several standard folders in a hierarchical structure. You will map your
existing config data into this data structure to enable the benefits that are described in [CDM data model](https://servicenow-prod.fluidtopics.net/ZN7eqYO5WCjS4cDDgfQaQQ "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.").
![Data structure for a new application. You will add your config data as nodes in the appropriate folder]()
The application supports creation of multiple deployables. For example, you might create a deployable for each typical environment: Development, Test, and Production. You might also create multiple versions of each deployable for each environment type.
2. Working in the CDM code editor, you now create a changeset --- a draft copy of the application that you can edit.
3. While working in the changeset, you create the following types of nodes in the appropriate folders. This process models the config data, that is, it prepares the application to map your source config data into the CDM data structure.
Note:
Starting with Configuration Data Management version 4.2, you can define a node using any UTF-8 character, including the forward slash (/).
4. Now that the structure is in place, you use the REST APIs or the CDM code editing panel to upload your existing configuration data into the changeset. The process is described in [Uploading your config data](https://servicenow-prod.fluidtopics.net/fI4gYiNoRrau~29INCo2Lg "You first create a new CDM application structure and then upload the existing config data into the structure."). For more information, see [CdmApplicationsAPI](https://www.servicenow.com/docs/access?context=applications-api&version=australia&pubname=australia-api-reference&ft:locale=en-US), [CdmChangesetsAPI](https://www.servicenow.com/docs/access?context=changesets-api&version=australia&pubname=australia-api-reference&ft:locale=en-US), and [CdmSnapshoAPI](https://www.servicenow.com/docs/access?context=snapshot-api&version=australia&pubname=australia-api-reference&ft:locale=en-US).
Note:
If you're uploading an XML or CSV file to import your existing config data into CDM, the CDM parser parses the data in a specific way. For more information, see [Parsing of XML files in CDM](https://servicenow-prod.fluidtopics.net/vlUWWn4qLazV6WiL9Afq8A "The CDM XML parser enables the parsing of attribute key-value pairs in XML files, so when you upload config data from an XML file into CDM, you can easily identify the attributes of each element in the CDM editor or list view.") and [Parsing of CSV files in CDM](https://servicenow-prod.fluidtopics.net/uoHe0~WoJwfrtiVzG2Sp1g "The CDM CSV parser enables parsing of data in CSV files, so when you upload config data from a Comma-Separated Values (CSV) file into CDM, you can easily identify the data format attributes and config data in the CDM editor or list view.").
You can upload the following types of datasets: component variables, components, collections, and deployables.
Components{#cdm-prep-app-for-upload__dle-component}
: 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{#cdm-prep-app-for-upload__dle-collection}
: 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{#cdm-prep-app-for-upload__dle-deployable}
: 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.
5. After the data is uploaded, you return to CDM. You update variable and override values so that the relatively small set of components and collections can provide config data for all three deployable environments. 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.
6. Now, save and commit the changeset. The system performs the following actions:
* Determine whether there are conflicts with other earlier commits. If the system reports a conflict, you must resolve it and recommit or create a changeset and redo your changes. For more information on conflict resolution, see [Conflicts between changeset commits](https://servicenow-prod.fluidtopics.net/~B0dBjKROqD9hL~XXI0Emw "Service delivery can include multiple teams working at the same time on config data with potentially hundreds of configuration changes every day. Because changes can be in conflict with earlier changes by a different user, CDM manages commits and snapshots to block commits that conflict. You are notified of changeset conflicts to help you to resolve them.").
* Push all changes into the data model of the application (the config data is persisted).
* Generate a snapshot of each deployable that is affected by the changes in the changeset. The system validates config data by executing specified policies against a snapshot. At the moment that the snapshot is created, the snapshot can be published and used to export the config data. Snapshots are permanent records that cannot be edited.
{#cdm-prep-app-for-upload__ul_hrq_nch_vrb}
{#cdm-prep-app-for-upload__ol_r22_zt2_44b}The source config data is now held in CDM tables. You can now manage the data as needed: map policies to each deployable so that the snapshots can be validated, validate the data in a snapshot (apply the policies), export config data, and so on.
Note:
You can map policies to an empty deployable, but that is not a typical procedure.
**Related concepts**
* [Changesets and version control in CDM](https://servicenow-prod.fluidtopics.net/OMj330gzq7HaF94jTdLBkA "A changeset is a draft copy of an application that you can update and save as often as needed. When you are satisfied with your changes, you can commit the changeset to apply the changes to the application. Committing")
* [Conflicts between changeset commits](https://servicenow-prod.fluidtopics.net/~B0dBjKROqD9hL~XXI0Emw "Service delivery can include multiple teams working at the same time on config data with potentially hundreds of configuration changes every day. Because changes can be in conflict with earlier changes by a different user, CDM manages commits and snapshots to block commits that conflict. You are notified of changeset conflicts to help you to resolve them.")
* [Validating and correcting configuration data](https://servicenow-prod.fluidtopics.net/ZTrkNB0IGlJwslSiidJazw "For every change to an environment, there may be tens or hundreds of rules (policies) that need to be checked. CDM enables you to auto-validate configuration data to ensure that configuration changes are error-free and policy-compliant before the config data is consumed.")
**Related tasks**
* [Define or update a component](https://servicenow-prod.fluidtopics.net/BKH7Lv5UIFJS3sHhuxgAEQ "Define or update a component while working in a changeset.")
* [Define or update a collection in an application](https://servicenow-prod.fluidtopics.net/fyAnRJ9O_C_WPyEIEFouPA "Define or update a collection while working in a changeset of a application.")
* [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.")