A regular part of Salesforce release manager’s day-to-day tasks is troubleshooting metadata deployment errors. My aim in this article is to give you insights on how you can resolve these errors and most importantly, to keep you up-to-date every time I encounter them during my day-to-day deployment process. This article would be a troubleshooting guide that you should bookmark as, I will be posting questions, along with answers, on how to resolve these errors.
What Are Different Ways To Search For Salesforce Deployment Errors?
There are different ways of troubleshooting salesforce deployment errors, one of them can be asking developers why are we getting these errors, secondly searching on Google and getting answers from salesforce community, salesforce.stackexchange.com and also you can be part of trailblazer community groups. As a last resort, if you are still not getting any answers, create a case with salesforce and hopefully they should be able to give you guidance on resolving these errors. My former method of resolving these problems involved creating a document and maintaining an excel sheet because at the end of the day they are all repetitive unless something unexpected occurs.
Frequently Asked Questions on Salesforce Deployment Errors
Lightning record pages are also known as Flexi pages in terms of Metadata API. You can deploy lightning record page assignments from your source org to the target org without any issues.
To deploy lightning record page as an org default you have to include Profiles, recordTypes, FlexiPage and Object to deploy assignments correctly.
To deploy lightning page as app default you have to include Profiles, recordTypes, FlexiPage and Custom Application in your package.
This is a very common error in salesforce and in order to resolve this issue, you have to make sure that overall org code coverage should be more than 75%.
When you deploy a package along with the test classes to production, you have the choice of running either the local test or specified test (most probably everyone will choose out of these two options).
Run Local Test: Make sure the package which you are deploying will cover at least 75% of test classes and the overall org percentage should be at least 75%.
Run Specified Test: If you use this option, all the specified test classes should have at least 75%, and it does not take into account the overall organization percentage.
An ideal practice would be to do a validation before going live.
#Note: I have also written an whole article regarding this test coverage:
https://sfdc247.com/2021/08/how-to-meet-salesforce-test-code-coverage-a-coverage-requirement.html
Search layouts and Compact layouts represent the metadata associated with objects in Salesforce. You must deploy the whole object in order to deploy both of these layouts in higher environments. When you deploy the whole object, you will also deploy the associated dependencies along with the layouts that are part of it, such as validation rules, Field Level Security, etc.
Therefore, I would recommend making these changes manually in your target organization as part of the post-manual steps.
In order to deploy custom metadata and its records, you need to include component types as custom metadata and customObject in your package and you must deploy them simultaneously in your target org.
There are different Einstein components with respect to Metadata API.
WaveApplication
WaveDashboard
WaveDataflow
WaveDataset
WaveLens
WaveXmd
WaveTemplateBundle
You have to include the above components in your package as per your requirement in order to deploy them to target organization.
If the same components you are deploying using changeSets in that case you have to include below components in your package.
Analytics Application
Analytics Dashboard
Analytics Dataflow
Analytics Dataset
Analytics WaveLens
Analytics WaveXmd
Analytics WaveTemplateBundle
#Note: In metadataApi, Einstein components are represented by Wave, and in change sets, by Analytics
I have seen this error while deploying DataFlows. It usually happens when a profile of a user does not have visibility for a field in the dataflow, it will cause the following error:
You can follow below URL by salesforce which has this answer;
https://help.salesforce.com/s/articleView?id=000336870&type=1
In this case you must enable sharing inheritance and select the objects to use as a sharing source.
#Note: Sharing inheritance is enabled by default in new Salesforce Environments.
How To Enable Sharing Inheritance
- Go To Setup | Quick Find box | enter Analytics, and then click Settings.
- Select Inherit sharing from Salesforce and Save.
How To Enable Sharing Inheritance for Synced Objects
If your environment has Data Sync enabled, enable sharing inheritance for each object that you want to use as a sharing source.
- Click on Data Manager under Tableau CRM Studio.
- Click Connect
- On the right end of the row for the object you want to enable, click the dropdown list.
- Click Row Level Sharing.
- Click Sharing inheritance on.
- Click Save.
You may encounter this error when deploying tab settings from the source org to the target org. In order to resolve this error, you must remove the below XML file from your profile.<tabVisibilities><tab>standard-DelegatedAccount</tab><visibility>DefaultOff</visibility></tabVisibilities>
#Note: It may work with change sets but it will fail when you use Metadata API for deployment.
When setting up queues, there are two major required setups one is choosing the Supported Objects and Queue Member.
Additionally, you should be able to query QueueSObject:
SELECT SObjectType FROM QueueSObject WHERE Queue.Name = 'Give Your Queue Name"For this Specific error ensure in the source org you have added supported Object for the queues.
Make sure you are including the layouts and customObjects into your deployment package. First retrieve custom object, Layouts and translations using package.xml and then deploy them to the target organization. This should resolve this issue.
The flowDefinition file is located in the flowDefinitions directory/folder of each package. It was deprecated by salesforce from version 44.0. Remove flow definition from the package and deploy changes to target org.
You can also follow this document: https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_flowdefinition.htm
As long as we add dependent values to controlling field values and deploy through Metadata API, changes in target org are reflected correctly. However, if we remove dependent values from controlling field values and deploy through Metadata API, dependencies are not removed.
Please refer to the below documentation: https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_field_types.htm#meta_type_valueset
As per the documentation “You can add field dependency values via Metadata API but not remove them”. It states that “we can add field dependency values via Metadata API but not remove them”.
Don’t Worry This List Is Not Over and If You have have questions ?
If you cannot find an answer to your question in our FAQ, you can always contact us
and we will be with you shortly.
After reading this post you would be having many questions and I would love to hear it from you and your team. Shoot any questions that you would like to discuss with me and we can find the best practice for retrieving metadata components in your project.You can always comment, contact me on LinkedIn and I will reply back you immediately
#Note: Publishing this content anywhere without consent of SFDC247 will result in lawsuit against copyright infringement
