How to Generate and Retrieve Package.xml in Salesforce Without Workbench

In plain words: A package.xml file is the blueprint manifest that tells Salesforce exactly which metadata components (like Apex classes, custom fields, flows, or layout definitions) you want to pull down from an org or deploy to another environment. While legacy tools like Workbench were once popular, modern Salesforce development uses the Salesforce CLI (sf), VS Code Extensions, and automated manifest generators to build and retrieve metadata faster and more securely.

In Salesforce development, managing metadata across development sandboxes, staging environments, and production orgs requires precise versioning. The package.xml file acts as the project manifest, specifying metadata types, member names, and API version numbers. With legacy web utilities like Workbench facing deprecation and security constraints, adopting command-line and IDE-driven manifest workflows is essential for modern Salesforce DevOps.

1. Structure of a Standard Package.xml Manifest

A standard metadata manifest file defines the exact components you wish to target, structured neatly in XML format under the <Package> envelope.

Sample Manifest Structure (manifest/package.xml)

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

2. Method 1: Using Salesforce CLI (sf)

The unified Salesforce CLI is the official, scriptable tool for creating manifests and retrieving source code directly into your local workspace.

Step-by-Step CLI Commands:

1. Generate Manifest from Metadata Types: Generate a manifest file on the fly for specific metadata components:

# Generate a package.xml containing specific metadata types
sf project generate manifest --metadata ApexClass --metadata CustomField --output-dir manifest

2. Retrieve Source Using the Manifest: Pull all metadata declared inside your manifest file into your local project directory:

# Modern unified CLI syntax
sf project retrieve start --manifest manifest/package.xml

# Legacy sfdx command (deprecated)
sfdx force:source:retrieve -x manifest/package.xml

360 Manifest Retrieval Card:

• Manifest Generator Command: sf project generate manifest
• Source Retrieval Command: sf project retrieve start -x manifest/package.xml
• Wildcard Support: Use <members>*</members> to grab all components of a given metadata type (except Custom Fields and Standard Objects).
• Org Connection: Targets your default authorized org or a specific alias using the --target-org flag.

3. Method 2: Visual Studio Code & Salesforce Extensions

For developers who prefer a visual interface, the Salesforce Extension Pack for VS Code offers integrated manifest tools directly inside the editor:

• Salesforce Org Browser: Click the Cloud icon in the VS Code sidebar to browse all metadata types in your connected org. Click the cloud download icon next to any component to retrieve it instantly without manually writing XML.
• Manifest Generation Command: Open the Command Palette (Ctrl+Shift+P or Cmd+Shift+P), type SFDX: Generate Manifest File, name the file, and select the metadata types you want to include.
• Right-Click Retrieval: Right-click directly on manifest/package.xml in your file explorer and select SFDX: Retrieve Source in Manifest from Org.

4. Method 3: Automated Community Generators & Metadata API Scripts

When you need to generate a full package.xml covering an entire org with hundreds of components, writing XML manually is error-prone. Modern alternatives include:

• Salesforce Package.xml Generator (VS Code Extension): A popular community extension that provides a searchable UI within VS Code to select components and automatically update your package.xml.
• Node.js / Python Metadata API Scripts: You can use libraries like JSforce to authenticate via OAuth and query the describeMetadata() API to generate clean manifests programmatically in CI/CD build pipelines.

5. Common Traps & Best Practices

Developer Trap: Using Wildcards on Custom Fields
Placing <members>*</members> under the CustomField metadata type does not retrieve custom fields on standard objects (like Account or Contact). To retrieve custom fields on standard objects, you must explicitly declare each field as Account.CustomField__c or retrieve the entire parent object.

Core Rule: Retire legacy browser utilities like Workbench in favor of the unified Salesforce CLI (sf) and VS Code Org Browser to maintain source tracking and secure authentication.

• Keep API Versions Aligned: Ensure the <version> tag in your package.xml matches your project's sfdx-project.json sourceApiVersion to avoid metadata schema mismatch errors.
• Deconstruct Large Manifests: Avoid creating monolithic manifests that retrieve every component in the org. Split manifests by feature or module (e.g., package-billing.xml, package-service.xml) to keep deployments fast and isolated.
• Leverage .forceignore: Use a .forceignore file in your project root to prevent unwanted org metadata from cluttering your version control system.

Summary

Retrieving and managing your package.xml manifest is a fundamental skill for Salesforce deployment workflows. By adopting the modern Salesforce CLI, taking advantage of VS Code's Org Browser, and leveraging automated manifest tools, developers can build repeatable, secure metadata deployment pipelines without relying on outdated external web tools.