DevOps

When we want to retrieve or deploy metadata to a Salesforce Org, we use package.xml either with ANT command or using SFDX. And when retrieving metadata from a Salesforce org, it is quite common to use wildcard character asterisk (*) to retrieve everything of that metadata type.

For example, the following is used in package.xml to retrieve metadata about all custom objects.

<?xml version=1.0 encoding=UTF-8 standalone=yes?>
<Package xmlns=http://soap.sforce.com/2006/04/metadata>
    <types>
        <members>*</members>
        <name>CustomObject</name>
    </types>    
    <version>53.0</version>
</Package>

But do note that some of the metadata type does not support wildcard characters. And even if you put wildcard character in your package.xml, nothing will be retrieved. These metadata types include:

1. ActionOverride
2. AnalyticSnapshot
3. CustomField
4. CustomLabel
5. Dashboard
6. Document
7. EmailTemplate
8. Folder
9. FolderShare
10. GlobalPicklistValue
11. Letterhead
12. ListView
13. Metadata
14. MetadataWithContent
15. NamedFilter
16. Package
17. PersonalJouneySettings
18. Picklist
19. ProfileActionOverride
20. RecordType
21. Report
22. SearchLayouts
23. SearchingSettings
24. SharingBaseRule
25. SharingReason
26. SharingRecalculation
27. StandardValueSet
28. Territory2Settings
29. ValidationRule
30. WebLink

References & Useful URLs

• Metadata API Developer Guide -> Metadata Types

When you want to deploy changes from one Salesforce org to another, you can choose any of the following tools to transport changes from one Salesforce org to another Salesforce org.

1. Change Sets
2. Force.com Migration Tool (ANT based)
3. SFDX Command Line Tool
4. Microsoft VS Code with Salesforce Extensions
5. 3rd Party AppExchange Product (e.g. Dreamfactory)

All these tools use Metadata API to extract and deploy changes. (Tools like “Force.com Migration Tool” can also be used to automate the backup your Salesforce org’s configuration).

However, the point to note here is that not all configurations are available through metadata API. For example, the following configuration components cannot be deployed using any of the tools mentioned above.

• Account Teams
• Activity Button Overrides
• Auto-number on Customizable Standard Fields
• Calendars
• Campaign Influences
• Case Contact Roles
• Case Feed Layouts
• Case Team Roles
• Console Layouts
• Multiline layout fields for contract line items
• Currency Exchange Rates
• Data Category Visibility Settings
• Delegated Administration
• Divisions
• File Upload and Download Security Settings
• Mail Merge Templates
• Multiline layout fields for opportunity teams
• Offline Briefcase Configurations
• Omni-Channel Queues and Omni-Channel Skills routing types for the LiveChatButton object
• Opportunity Big Deal Alerts
• Opportunity Update Reminders
• Organization Wide Email Addresses
• Partner Management
• The following standard picklists: IdeaTheme.Categories, Opportunity.ForecastCategoryName, Question.Origin. (All other standard picklists are supported.)
• Predefined Case Teams
• Quote Templates
• Salesforce to Salesforce
• Self-Service Portal Font and Colors
• Self-Service Portal Users
• Self-Service Public Solutions
• Self-Service Web-to-Case
• Service report templates
• Social Business Rules
• SoftPhone Layout
• Solution Categories
• Solution Settings
• Standard fields that aren’t customizable, such as auto-number fields or system fields
• Web Links on Person Account Page Layouts
• Web-to-Lead

These components will need to be manually created in the target Salesforce org.

Also, if you are taking backups of your metadata using any of the tools mentioned above, then you should also consider documenting the configuration settings of unsupported components so that they can manually be re-created if required.

Salesforce comes up with 3 product releases every year. The list of components mentioned above may get supported by Metadata API in new releases.  To view the updated list of components that is NOT supported by Metadata API, please visit  URL https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_unsupported_types.htm

Implementing Salesforce or already using Salesforce? Do you have a well-defined development & release management process to ensure that you are doing it the right way, using all the proper tools & technologies, automating processes where it can and should be automated?

Do you have a proper process to ensure that you are building an optimal solution on Salesforce, leveraging on the platform’s features and capabilities, not incurring technical debt and not cutting corners on best practices?

Have you laid down the design/technical standards and best practices and made it mandatory for all admins, consultants, developers to read and follow it? Have you baked in a formal process to review the solution design before and after the build?

If not, the following quote from Steve Jobs may force you to pause and think if you are doing things the right way.

We had a fundamental belief that doing it right the first time was going to be easier than having to go back and fix it. And I cannot say strongly enough that the repercussions of that attitude are staggering. I’ve seen them again and again throughout my business life.

Steve Jobs

But it may still not be too late. Why not take a look at the following development & release management process for Salesforce and see this something that you would like to use. You can start with this as a base and then modify/fine-tune it as per your requirement. This will also help you come up with a formal and documented process.

But I don’t claim to be an expert in Development & Release Management. The process that I have defined here is based on my experience & observations. 

If you have any recommendations on how the whole process can be made even better or if I have missed out anything, please do let me know in the comments below and I will reach out to you for further collaboration.