Retrieving Salesforce Metadata for CI/CD with CLI Tools

Question:

I am new to setting up CI/CD for Salesforce and am trying to sync metadata from a Dev Hub org to my local project. Here’s how I created my project repository:

sf project generate -n sfdemo -x

This command generated the following project structure:

/home/uniwinux/repo
  ├── sfdemo/config/project-scratch-def.json
  ├── sfdemo/manifest/package.xml
  ├── sfdemo/README.md
  ├── ...

The manifest/package.xml file looks like this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>*</members>
        <name>ApexClass</name>
    </types>
    <types>
        <members>*</members>
        <name>ApexTrigger</name>
    </types>
    <types>
        <members>*</members>
        <name>CustomTab</name>
    </types>
    <types>
        <members>*</members>
        <name>CustomApplication</name>
    </types>
    <types>
        <members>*</members>
        <name>LightningComponentBundle</name>
    </types>
    <types>
        <members>*</members>
        <name>CustomField</name>
    </types>
    <version>62.0</version>
</Package>

I created metadata like custom objects, tabs (Employee, Skill, Manager), an Apex class (HelloWorld), an Apex trigger (TriggerStudent), a Lightning Web Component app (My App LWC), and some custom fields. After logging in using sf org login jwt, I tried retrieving these using:

sf project retrieve start -o $user --manifest manifest/package.xml

However, only the Apex trigger (TriggerStudent) was retrieved. No tabs, apps, Apex classes, or custom fields were fetched. Upon further research, I found that explicitly specifying the metadata in the package.xml works.
For instance:

<types>
    <members>HelloWorld</members>
    <name>ApexClass</name>
</types>
<types>
    <members>Account.Hello_World__c</members>
    <name>CustomField</name>
</types>

Why doesn’t the wildcard (*) in the original package.xml fetch all metadata? How can I ensure all metadata is retrieved?

Answer:

The issue arises because not all metadata types in Salesforce can be retrieved with a wildcard (*) in the package.xml. Some metadata types, such as CustomApplication, CustomField, and CustomTab, require explicit inclusion or specific naming in the manifest file to be retrieved.

Solution 1: Explicitly Include Metadata Members in package.xml

To retrieve specific metadata, explicitly list their names in the package.xml.
For example:

<types>
    <members>HelloWorld</members>
    <name>ApexClass</name>
</types>
<types>
    <members>Account.Hello_World__c</members>
    <name>CustomField</name>
</types>
<types>
    <members>My_App_LWC</members>
    <name>CustomApplication</name>
</types>
<types>
    <members>Employee</members>
    <members>Skill</members>
    <members>Manager</members>
    <name>CustomTab</name>
</types>

The provided XML code is a part of a Salesforce package.xml file, which is used to define the metadata components you want to retrieve or deploy in Salesforce. Here’s a breakdown of the code:

CRS Info Solutions provides top-notch Salesforce online course with real-time projects, certification guidance, interview coaching, and a practical, job-ready approach.

Explanation:

1. ApexClass:

<types>
    <members>HelloWorld</members>
    <name>ApexClass</name>
</types>

• <members>: Specifies the name of the Apex class (HelloWorld) to be retrieved or deployed.
• <name>: Specifies the metadata type as ApexClass.
• Purpose: This entry instructs Salesforce to include the HelloWorld Apex class in the retrieval or deployment process.
  
  2.Custom Field:

<types>
    <members>Account.Hello_World__c</members>
    <name>CustomField</name>
</types>

• <members>: Specifies the API name of a custom field (Hello_World__c) on the Account object. Custom fields are always defined as <ObjectAPIName>.<FieldAPIName>.
• <name>: Specifies the metadata type as CustomField.
• Purpose: This entry fetches the Hello_World__c custom field from the Account object during metadata retrieval or deployment.
  
  3.CustomApplication:

<types>
    <members>My_App_LWC</members>
    <name>CustomApplication</name>
</types>

• <members>: Specifies the name of a custom application (My_App_LWC) to retrieve or deploy.
• <name>: Specifies the metadata type as CustomApplication.
• Purpose: This entry retrieves the My_App_LWC application, which may be a Lightning Web Component app or any custom application defined in the org.
  
  4.CustomTab:

<types>
    <members>Employee</members>
    <members>Skill</members>
    <members>Manager</members>
    <name>CustomTab</name>
</types>

• <members>: Lists the API names of custom tabs (Employee, Skill, Manager) to retrieve or deploy.
• <name>: Specifies the metadata type as CustomTab.
• Purpose: This entry retrieves the custom tabs (Employee, Skill, Manager) that may correspond to custom objects, visualforce pages, or web links.

Solution 2: Retrieve Metadata Using Metadata API Queries

Use the Salesforce CLI’s metadata commands to retrieve metadata dynamically.
For example:

sf metadata list -o $user --metadata ApexClass
sf metadata list -o $user --metadata CustomTab
sf metadata list -o $user --metadata CustomApplication

Explanation:

• sf metadata list -o $user --metadata ApexClass
  This command lists all Apex classes available in the specified Salesforce org. The output will include the names of Apex classes that you can retrieve or work with in your local project.
• sf metadata list -o $user --metadata CustomTab
  This command lists all custom tabs in the specified Salesforce org. Custom tabs could be for objects, web pages, or Lightning pages created in Salesforce.
• sf metadata list -o $user --metadata CustomApplication
  This command lists all custom applications (e.g., apps you see in the Salesforce App Launcher) in the specified Salesforce org.

Use Case:

These commands are useful when you want to:

• Discover what metadata exists in the org for a specific type.
• Identify metadata names to include in your package.xml for retrieval.
• Verify that certain metadata exists before attempting to retrieve or deploy it.

After listing the available metadata, update your package.xml with the names you want to retrieve. You can automate this process using scripts to dynamically generate the package.xml.

Solution 3: Use Unlocked Packages or Scratch Orgs for CI/CD

If you are working on CI/CD pipelines, consider defining metadata dependencies through unlocked packages or scratch org configuration files. These approaches standardize metadata management and streamline retrieval processes.

Summing Up:

In summary, the wildcard (*) doesn’t work universally for all metadata types in Salesforce. Explicitly defining the metadata in package.xml or using the CLI to list and retrieve metadata dynamically can solve the problem.

Looking for top-notch Salesforce training in Noida? CRS Info Solutions offers comprehensive courses with a focus on real-time project scenarios for hands-on experience. Our expert instructors guide you through Admin, Developer, and AI modules, preparing you for certification and interviews. With detailed class notes and practical learning, we ensure you’re industry-ready. Enroll today for a free demo session and get started on your Salesforce career! Enroll for our Salesforce training in Noida.