Salesforce DX Source Format

Updated 3 weeks ago by Copado Solutions

Please note that DX format is a pilot project and there are some limitations with other features. There are currently no more places available for this pilot.


Copado now supports Salesforce DX source format. Salesforce DX source format provides a source format that separates metadata into more granular folders. This can be very useful when working with version control systems as source files are split up into smaller files, thus making it easier for you to find the piece of information you are looking for. 

This format has changed the structure of the following metadata types: Custom Objects, Custom Object Translations, Aura Components, Lightning Web Components, Static Resources and Documents. In the case of a custom object, this means that each object file will be contained in its own folder and the following nested components will have their own files: businessProcesses, compactLayouts, CustomField, FieldSet, ListView, RecordType, SharingReason, ValidationRule and WebLink.

Copado will be supporting the DX source format in all the branches involved in the pipeline, that is, environment branches, feature branches and promotion branches. As part of this new feature, Copado will be enhancing snapshots, commits, promotions and deployments.


A snapshot in Copado represents a connection between a Salesforce environment and a Git repository/branch. When you create a Git snapshot, Copado retrieves all the metadata from the org selected and converts it. Then, when committing the metadata, Copado follows this order:

  1. If you have a copado_root file, Copado will add the metadata at that level.
  2. If you don’t have a copado_root file but have a src folder, Copado will add the metadata in the src folder.
  3. If you have neither a copado_root file nor a src folder, Copado will add the metadata to the root folder in your repository 
Please note that only one root folder will be supported.

A commit is a process used in Copado to link changes to a user story and then record these changes in a Git repository. Copado will apply the same logic as in a Git snapshot and will convert the project and then commit this into the feature branch.


A promotion is a container used to deploy one or multiple user stories from one environment to another. In a promotion, there is no conversion, since all the branches of all the user stories included in the Promotion record will already be in DX format. Once the deployment resulting from the promotion is executed, Copado will use the Smart conflict resolution feature to resolve either manually or automatically any merge conflicts that may arise among the feature branches.


A deployment is the process of moving changes from one environment to another. If a Deployment record already exists and the DX promotion branch has already been created and referenced, Copado will convert the codebase back to mdapi on the run so that all the process of building the package and deploying happens in the same way as now.


To enable this feature, all you need to do is select DX from the Source Format picklist field when creating a new Git repository.

Important Considerations

Part of Copado’s functionality is based on how the metadata API structures XML files. Therefore, it is important to bear the following in mind:

Semantic Merge

A semantic merge is applied in Copado when two or more changes are made to the same object or permission set, for instance, in different user stories. There might not actually be a conflict, but Git will interpret this as such, and Copado will resolve it by merging all the changes into one file.

This functionality will still be applied to those metadata types that are not changing (e.g. profiles and permission sets). A semantic merge will not be applied to objects and fields, as this is not required. The folder and file structure will take care of this.

Online Conflict Resolution

Copado supports this feature for all metadata types, including those that are changing, such as CustomObjects, which rarely contain a merge conflict.

Static Code Analysis

SCA will be working for all metadata types, as only code is analyzed and the structure is preserved.

How did we do?