January 14, 2021
Decoding Salesforce Metadata API Nuances for Faster Deployments

Decoding Salesforce Metadata API Nuances for Faster Deployments

Salesforce metadata API is powerful and much of Salesforce’s power would just not be possible without it! As the backbone of most deployment and migration tools and IDEs, metadata API is used for managing customizations and the tools that can manage the metadata model. Yet the metadata API can be really quirky and losing control of your metadata seems like your worst nightmare. This blog highlights how working around their special use cases and nuances helps to speed up deployment. Further, we also discuss how Flosum, as your all-in-one DevOps solution for Salesforce allows metadata deployments, continuous integration, metadata backups, data deployment, and data backup to make deployment powerful, fast easy, and secure.

What is Salesforce Metadata API?

The Salesforce Metadata API (Application Programming Interface) is used to retrieve, deploy, create, update, or delete customization information, such as custom object definitions and page layouts for your organization. Your profiles, schema, custom objects to the custom tab and other customizations can be all captured by the metadata API. The metadata representation can be stored in the version control and forms the basis for automated processes that include automated deployments. Metadata API is also useful for looking for customizations in a Salesforce Org and then moving those customizations from one org into another org. Metadata API is used to manage setup and customization information (metadata) for your organizations.

Working Around Nuances of Metadata API

Although metadata is core to Salesforce’s infrastructure, there are certain quirks about the metadata API that need to be considered to mitigate risks and have better control of the metadata and your org.

  • Deploying Managed and Unmanaged Packages

Apart from using the Salesforce ANT Migration tool, the other option for moving metadata from one org to another org is using Packages. However, the process followed is different for both managed and unmanaged packages. For instance, for the unmanaged package, you have to explicitly list every asset and child asset type by name as well as specify the “full name” parameter to move the unmanaged package between the orgs. Whereas, the ‘Installed Package’ metadata type is used to deploy a managed package. These are always named after the name space of the currently installed package. When deployed, these trigger an acknowledgement – These are perhaps the only metadata asset type that sends one.

  • “Peculiar” List metadata results

The List Metadata gives you a list of any metadata asset type such as custom objects, custom tabs, and standard objects. But it also does strange things! There are times when you ask the metadata API for custom objects, and it will give you all of your custom objects but only some of your standard objects because list metadata API will only return you custom objects that are relevant to the metadata. Similarly, the list metadata will give you all the custom permissions in an org but not the user permissions. The reason being that unless you turn them on, you cannot really see them in an org. The list metadata will also return all the custom tabs except those that have the standard(dash) prefix, this often is a problem since you are not getting complete information about your standard objects or tabs that you need to know about.

  • “Weird” Page Layout Names and Managed Packages

A page layout can be for custom objects, standard objects, or managed packaged objects. However, List Metadata handles page layouts that are very tricky since it returns unpackaged layout names for all packaged layouts. As a result, most of the tools get it wrong, and therefore if you want to retrieve it, you have to look through the metadata results and see if they gave you a name space. If so, you have to insert the namespace before the page layout name.

  • “Fleeting” Translation Comments

This relates to the bunch of translations in Salesforce, such as custom object translations (where you translate all the parts of the interface). If you retrieve a translation file and then deploy the same file without making any changes, then Salesforce metadata API will replace each XML comment with an empty string. The problem is that when you receive it, you will get the comment but when you deploy it, it removes the comment every time. Therefore, you have to remove all the comments in bold when you put any translation back into deployment.

  • Standard Assets Complexify Deployments

Dependency between custom assets and standard assets tend to complicate deployments. Salesforce usually has three releases a year and each time it also rolls out sandboxes and production orgs. There are multiple orgs in the Salesforce ecosystem, and a lot of time the orgs have different standard features. The challenge is that you can’t delete or migrate these standard assets or even add them to deployment and so if they are entangled with other data or objects, it will stop all your deployments if they are between different orgs or versions of Salesforce. Moreover, standard assets are difficult to discover, and often the only way to discover them is when a metadata API shows an error, which further causes problems too.

Ready to take your Salesforce Deployment to the next level?

In face of these challenges, building the right process to accelerate the deployment and release cadence becomes critical. Implementing DevOps to your Salesforce projects allows you to automate release management and deployment. Choosing a fully Salesforce native release management and version control system to automate release pipeline release management not only allows you to reap the benefits of a shorter feedback loop and cut back on the deployment time, but it also boosts deployment success rates and increases release cadence.

Next Steps