Metadata Specificities

Metadata Specificities

The Salesforce metadata has a few specificities It is retrievable in two formats (source and old metadata)

This document explain some of the specificities of the source metadata handled by the plugin itself to have the best deployment experience.

CustomObject order in package.xml

We implemented an algorithm to sort the types and the members alphabetically in the package.xml but we encountered a few weird issue when a CustomObject was listed after some metadata depending on it.

We deduced the CustomObject metadata order in the package.xml can lead to a deployment failure when other metadata depending on it are listed before in the package.xml.

It means the order of declaration of metadata element in the package.xml is important for the success of the deployment.

So we implemented a custom rule for sorting the types in the package.xml making sure the CustomObject are listed first.

Deploying master detail field

The metadata API can throw an error when the parent object is not added

We implemented a custom algorithm to add the parent object definition of a master detail field when this field is added in the package.xml We implemented a custom algorithm to add the master detail fields definition of a CustomObject field when a CustomObject is added in the package.xml.

This way, when deploying both, the hidden required metadata is added automatically

FieldTranslation with ObjectTranslation

FieldTranslation are not deployable when ObjectTranslation are not listed in the package.xml.

We implemented a custom algorithm to add the ObjectTranslation when a FieldTranslation is added to the package.xml

This way, when deploying FieldTranslation, the hiddenly required ObjectTranslation metadata is added automatically.

Metadata contained inside file with their container

Metadata contained inside file need to be deployed with their container so the deployment can succeed. The content of the file deployed can be stripped to contain only the element to deploy but the package.xml need to have the container listed as well.

Per example, deploying only a WorkflowRule with a package.xml will not work if the Workflow container is not listed as well.

We implemented a custom algorithm to add the inFile metadata container as well.

Do not add "not deletable via metadata API" members in the destructiveChanges.xml

Some metadata types are deployable via metadata API but not deletable (example RecordType and Here)

We implemented an enhancement request to deal with those kind of metadata.