How to Retrieve All Salesforce Metadata Using Package.xml and Salesforce CLI

In plain words: In Salesforce, package.xml is a manifest file that lists the configuration components (like Apex classes, custom fields, flows, and Lightning web components) you want to extract from an org or deploy to another environment using Metadata API tools and the Salesforce CLI.

Whether you are establishing a local Git repository, backing up an org configuration, or running automated CI/CD deployment pipelines, understanding how to construct and execute a package.xml manifest is a fundamental skill for every Salesforce developer and DevOps engineer.

1. Anatomy of a package.xml Manifest

A standard package.xml file is wrapped inside a root <Package> element. It contains one or more <types> blocks that define the components to retrieve, followed by the target Metadata API <version>.

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>*</members>
        <name>ApexClass</name>
    </types>
    <types>
        <members>*</members>
        <name>LightningComponentBundle</name>
    </types>
    <version>60.0</version>
</Package>

Warning Trap — The Universal Wildcard Myth: You cannot write <name>*</name> to download every single metadata type in your Salesforce org simultaneously. The Metadata API requires an explicit <name> for each metadata type (such as ApexClass, CustomObject, or Flow). You can only use the wildcard (*) inside the <members> tag to retrieve all items of that specific type.

2. Sample Comprehensive package.xml for Common Metadata

Below is a production-ready manifest covering the most frequently migrated and backed-up Salesforce metadata components:

<?xml version="1.0" encoding="UTF-8"?>
<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>ApexComponent</name>
    </types>
    <types>
        <members>*</members>
        <name>ApexPage</name>
    </types>
    <types>
        <members>*</members>
        <name>AuraDefinitionBundle</name>
    </types>
    <types>
        <members>*</members>
        <name>LightningComponentBundle</name>
    </types>
    <types>
        <members>*</members>
        <name>CustomObject</name>
    </types>
    <types>
        <members>*</members>
        <name>CustomField</name>
    </types>
    <types>
        <members>*</members>
        <name>Flow</name>
    </types>
    <types>
        <members>*</members>
        <name>PermissionSet</name>
    </types>
    <types>
        <members>*</members>
        <name>CustomTab</name>
    </types>
    <types>
        <members>*</members>
        <name>Layout</name>
    </types>
    <version>60.0</version>
</Package>

3. Retrieving Folder-Based and Parent-Child Metadata

Certain metadata types follow specific naming conventions due to folder hierarchies or parent-child data models:

• Reports, Dashboards, and Email Templates: Require folder names before the item name (e.g., <members>Sales_Reports/Quarterly_Pipeline</members> or <members>unfiled$public/Welcome_Email</members>).
• Custom Fields & Validation Rules: Child components require the parent object prefix when retrieved individually (e.g., <members>Account.SLA_Expiration_Date__c</members> under <name>CustomField</name>).
• Custom Metadata Types & Custom Settings: Treated as custom objects ending in __mdt and __c under <name>CustomObject</name>.

4. How to Retrieve Metadata Using the Salesforce CLI

Once your package.xml file is saved in your project root or manifest directory (e.g., manifest/package.xml), run the standard Salesforce CLI (sf) retrieval command:

CLI Retrieval Commands:

# Retrieve metadata using the manifest file
sf project retrieve start --manifest manifest/package.xml

# Alternatively, automatically generate a package.xml manifest from your org
sf project generate manifest --source-dir force-app --output-dir manifest

360 Architecture Summary:

• Manifest Location: Store manifest files inside the standard manifest/ folder in modern Salesforce DX projects.
• Source Format vs. Metadata Format: The CLI extracts retrieved metadata into modular Salesforce DX source format (force-app/main/default) for easier Git versioning.
• Automated Manifest Generation: Use VS Code extensions (like Salesforce Package.xml Generator) or CLI commands to build manifests without manual XML editing.

Core Takeaway: While you cannot use a wildcard across metadata types, defining explicit types with wildcard members in package.xml combined with sf project retrieve start provides a reliable, automated mechanism to extract org metadata for version control and migration.