Reference - CI/CD object types

The Continuous Integration and Continuous Deployment features support the following types of Xperience objects:

General
Content management
Digital marketing
Binding object types

Related pages

General

Object type	CI/CD folder name	Notes
Alternative forms	cms.alternativeform	Used by the Xperience administration. Contains definitions of UI forms used to provide editing interfaces for object types. Child object type of Module class objects.
Channels	cms.channel	A medium for delivering content via a specific method (website, email, social networks).
Consents	cms.consent	Includes consent definitions, with all consent texts. CI/CD does not include archived consents or consent agreements given by contacts.
Languages	cms.contentlanguage
Modules	cms.resource	Used internally by the Xperience administration and data structure.
Module classes	cms.class	Includes the definitions and settings of module classes (object types). Used internally by the Xperience administration and data structure. Supported child objects: Alternative forms (cms.alternativeform)
Module classes - Customizable	cms.systemtable	Includes the definitions and settings of certain module classes (object types). Used internally by the Xperience administration and data structure. Supported child objects: Alternative forms (cms.alternativeform) Queries (cms.query)
Notification emails	cms.notificationemail
Notification email templates	cms.notificationemailtemplate
Queries	cms.query	Used internally by the system. Child object type of Module class objects.
Roles	cms.role
Scheduled task configurations	cms.scheduledtaskconfiguration	Information about scheduled task execution intervals and other metadata.
Setting categories and groups	cms.settingscategory	The cms.settingscategory object type includes both setting categories and setting groups.
Settings	cms.settingskey	Settings are supported, but *excluded by default* in the repository.config file. Settings may contain sensitive data – only remove the exclusion if you agree to make setting values available within the file system used by your application and any connected source control systems. You can configure the repository.config file to include settings in general, but exclude individual setting keys that you consider sensitive. Important: The License key (Settings -> System -> Licenses) setting that stores the license key used to activate the instance is excluded permanently regardless of your repository.config configuration.
Users	cms.user	User accounts for the administration interface.
Workspaces	cms.workspace

Content management

Object type	CI/CD folder name	Notes
Content types	cms.contenttype	Stores content type definitions.
Content items	contentitemdata.* cms.contentitem cms.contentitemcommondata cms.contentitemlanguagemetadata	The system uses multiple files to store content item data. See the Content items section of CI/CD repository structure for more information. CI/CD data does not include changes made to new versions of previously published content items. While an item is in the Draft (New version) status (or a custom workflow step), CI/CD stores the original published version, until the new changes are published. Consequently, the published version of content items is always restored by CI/CD – any changes made in Draft (New version) or custom workflow steps are lost when the item is restored. Content item asset fields Binary data managed by fields of the Content item asset data type is serialized into the repository together with the source content item objects – on instances using CI/CD, the binary data exists in two copies: one in the ~/assets folder and the second in the repository. Note: Changing the data type of Content item asset fields or removing these fields entirely will result in abandoned binary files in the repository. To remove these unwanted files, serialize all objects again, which recreates the repository without the orphaned files.
Content folders	cms.contentfolder	Stores folders used to organize items in the Content hub application. Required for all projects to ensure that the content hub works correctly. The CI/CD files storing content hub folder data are organized into file system subfolders named according to each content hub folder’s parent. The hierarchy starts from a “root” system folder. Smart folders are stored separately as cms.smartfolder objects.
Headless channel configuration	cms.headlesschannel	Child object type of Channel objects.
Headless items	contentitemdata.* cms.contentitem cms.contentitemcommondata cms.contentitemlanguagemetadata cms.headlessitem	The system uses multiple files to store headless item data. See the Headless items section of CI/CD repository structure for more information. CI/CD data does not include changes made to new versions of previously published headless items. While an item is in the Draft (New version) status (or a custom workflow step), CI/CD stores the original published version, until the new changes are published. Consequently, the published version of headless items is always restored by CI/CD – any changes made in Draft (New version) or custom workflow steps are lost when the item is restored.
Media library files	media.file	Child object type of Media library objects. Only includes media file definitions, not the binary data of individual media files. Binary data is stored on the file system in the media library folders.
Pages	contentitemdata.* cms.contentitem cms.contentitemcommondata cms.contentitemlanguagemetadata cms.webpageitem	The system uses multiple files to store page data. See the Pages section of CI/CD repository structure for more information. CI/CD data does not include changes made to new versions of previously published pages. While a page is in the Draft (New version) status (or a custom workflow step), CI/CD stores the original published version, until the new changes are published. Consequently, the published version of pages is always restored by CI/CD – any changes made in Draft (New version) or custom workflow steps are lost when the page is restored. CI/CD data also does not include changes made to page permissions. After performing the CD restore operation, the moved and newly created pages inherit permissions from their new parent page. Supported child objects: Page former URL paths (cms.webpageformerurlpath) Page URL paths (cms.webpageurlpath)
Page former URL paths	cms.webpageformerurlpath	Child object type of Page objects.
Page URL paths	cms.webpageurlpath	Child object type of Page objects.
Preset page templates	cms.pagetemplateconfiguration	The Page Builder configuration of a saved preset page template created using a default page template.
Reusable field schemas	cms.class	Reusable field schema definitions are stored as part of the CMS.ContentItemCommonData object. If your content types use reusable field schemas and you want to track changes to their structure, make sure to include reusable field schema definitions into your repository. This is particularly relevant for SaaS projects that need to explicitly opt-in for each CI/CD object. Tracking reusable field schemas in CI/CD requires the following includes in repository.config. XML Add reusable field schema definitions to CI/CD `<IncludedObjectTypes> <ObjectType>cms.class</ObjectType> </IncludedObjectTypes> <ObjectFilters> <IncludedCodeNames ObjectType="cms.class"> <!-- Contains reusable field schema definitions --> CMS.ContentItemCommonData </IncludedCodeNames> </ObjectFilters>` Data stored in reusable schema fields are included in content items.
Smart folders	cms.smartfolder	Stores smart folders, which are used to dynamically categorize and filter items in the Content hub application. The content folder hierarchy in the Content hub application is stored separately using cms.contentfolder objects.
Taxonomies	cms.taxonomy
Tags	cms.tag	Tags that belong under another tag in the taxonomy tree are stored as child objects in the CI/CD repository. CI/CD files representing child tags are placed under subfolders named according to the parent tag.
Website channel configuration	cms.websitechannel	Child object type of Channel objects.
Workflows	cms.contentworkflow	Supported child objects: Workflow step (cms.contentworkflowstep)
Workflow step	cms.contentworkflowstep	Child object type of Workflow (cms.contentworkflow) objects.

Digital marketing

Object type	CI/CD folder name	Notes
Activity types	om.activitytype
Automation processes	ma.automationprocess	Stores automation processes. CI/CD data does not include information about contacts passing through automation processes, or the contact history and other statistics of automation steps. Also required to ensure the functionality of all types of form autoresponders, which internally use automation. Note: If you delete or significantly restructure the steps in a process, and then CI/CD restore these changes on an instance where the process is already enabled or has contact history, you may break the process or cause inconsistencies. This scenario is not supported. Supported child objects: Automation steps (ma.automationstep) Automation triggers (cms.objectworkflowtrigger)
Automation actions	ma.automationaction	Stores data representing the step types that perform specific actions within automation processes (e.g., “Send email”). Also required to ensure the functionality of all types of form autoresponders, which internally use automation. Required for all projects to ensure system functionality that internally uses automation processes.
Automation steps	ma.automationstep	Stores steps within automation processes (Automation Builder). CI/CD data does not include information about contacts passing through automation processes, or the contact history and other statistics of automation steps. Also required to ensure the functionality of all types of form autoresponders, which internally use automation. Note: If you delete or significantly restructure the steps in a process, and then CI/CD restore these changes on an instance where the process is already enabled or has contact history, you may break the process or cause inconsistencies. This scenario is not supported. Child object type of Automation process objects.
Automation triggers	cms.objectworkflowtrigger	Stores the triggers of automation processes. Also required to ensure the functionality of all types of form autoresponders, which internally use automation. Child object type of Automation process objects.
Contact groups	om.contactgroup	Only includes the definitions of contact groups, without information about the contacts assigned to the groups. Additionally, the CI/CD data does not contain information about scheduled rebuilds for contact groups. After restoring a new condition-based contact group from the repository folder, you need to manually rebuild the group in the Contact groups application.
Countries	cms.country	Supported child objects: States (cms.state)
Email channel configuration	emaillibrary.emailchannel	Supported child objects: Email channel sender address
Email channel sender addresses	emaillibrary.emailchannelsender	Child object type of Email channel configuration objects.
Emails	contentitemdata.* cms.contentitem cms.contentitemcommondata cms.contentitemlanguagemetadata emaillibrary.emailconfiguration	The system uses multiple files to store email data. See the Emails section of CI/CD repository structure for more information. CI/CD data does not include changes made to new versions of previously published emails. While an email is in the Draft (New version) status (or a custom workflow step), CI/CD stores the original published version, until the new changes are published. Consequently, the published version of emails is always restored by CI/CD – any changes made in Draft (New version) or custom workflow steps are lost when the email is restored. Does not include statistics tracked for emails.
Email templates	emaillibrary.emailtemplate
Forms	cms.form cms.formclass	Only includes form definitions and settings, not the data records stored by individual forms. The system uses multiple object types to store the definitions and settings of forms. See the Forms section in CI/CD repository structure for more information.
Form featured fields	cms.formfeaturedfield	Stores the definitions of fields displayed in the Featured category when adding fields to forms.
Macro rules	cms.macrorule	Used internally for the condition builder in contact group and automation processes.
Macro rule categories	cms.macrorulecategory	Used internally for the condition builder in contact group and automation processes.
Recipient lists	om.recipientlist	Stores recipients lists, which contain contacts who opt in to receive regular emails. Only includes the recipient list definition, without information about the contained recipients. Supported child objects: Recipient list settings (emaillibrary.recipientlistsettings)
Recipient list settings	emaillibrary.recipientlistsettings	Stores the approval and unsubscribe settings of recipient lists. Child object type of Recipient list objects.
States	cms.state	Child object type of Country objects.
Tracked websites	om.trackedwebsite	Websites registered for the Cross-site tracking feature.

Binding object types

In addition to standard object types, CI/CD also supports most related bindings (i.e. objects representing relationships between the supported objects and other objects).

Binding	CI folder name	Main object type (parent)	Related object type
Application permissions	cms.applicationpermission	Role	No regular object type. The binding connects roles to application identifiers (defined in code when registering an admin UI application) and permission identifiers (defined in code when specifying the set of permissions available for an application).
Automation process step transitions	cms.workflowtransition	Automation step	Automation step
Content item reference	cms.contentitemreference	Content item	Content item
Allowed content types for channels	cms.contenttypechannel	Channel	Content type
Allowed email templates for content types	emaillibrary.emailtemplatecontenttype	Content type	Email template
Email sendout settings	emaillibrary.sendconfiguration	Email	Recipient list
Macro rules assigned to categories	cms.macrorulemacrorulecategory	Macro rule category	Macro rule
Users in roles	cms.userrole	Role	User
Workflow content type	cms.contentworkflowcontenttype	Content workflow	Content type
Workflow roles with full control	cms.contentworkflowrole	Content workflow	Role
Workflow step roles	cms.contentworkflowsteprole	Content workflow step	Role
Workspace data permissions	cms.workspacedatapermission	Role	No regular object type. This object type, for a given workspace, connects a role to application identifiers (which support being scoped under Workspaces) and workspace permission identifiers (defined in code when specifying the set of workspace permissions available for an application).