Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
Full Project Manifest entry
How-to guide

How to build and use a package.xml manifest

You build a package.xml manifest either by generating it from an org with the Salesforce CLI or by editing the XML directly. The CLI route is faster and avoids most wildcard mistakes. Here is the generate-then-use flow.

By Dipojjal Chakrabarti · Founder & Editor, Salesforce DictionaryLast updated Jun 16, 2026

You build a package.xml manifest either by generating it from an org with the Salesforce CLI or by editing the XML directly. The CLI route is faster and avoids most wildcard mistakes. Here is the generate-then-use flow.

  1. Open a DX project

    Run the commands from the root of a Salesforce DX project, the folder that contains sfdx-project.json. The CLI needs that configuration present to know your package directories.

  2. Generate the manifest

    Run sf project generate manifest --from-org YourOrgAlias --output-dir manifest to capture what exists in an authorized org, or use --source-dir force-app to build it from local source. The command writes package.xml into the manifest folder.

  3. Trim and set the API version

    Open the generated package.xml, remove types you do not want, and confirm the version element matches the API version you intend to deploy against, for example 61.0.

  4. Use it in a command

    Retrieve with sf project retrieve start --manifest manifest/package.xml, or deploy with sf project deploy start --manifest manifest/package.xml. Add --dry-run on a deploy to validate before committing changes.

Mandatory fields
typesrequired

One block per metadata grouping. Each block holds its members and a single name.

membersrequired

The API name of a component, or an asterisk to request every component of that type. Standard objects and their custom fields are not returned by a bare wildcard.

namerequired

The metadata type for the block, such as ApexClass, CustomObject, or Flow. Exactly one per types block.

versionrequired

The API version for the operation, such as 61.0. One per file, at the Package root level.

Gotchas
  • A wildcard on CustomObject skips standard objects and skips custom fields on standard objects. Name those explicitly.
  • Types tied to an object (CustomField, RecordType, ValidationRule, WebLink, Picklist) must be dot-qualified, like Account.My_Field__c.
  • package.xml never deletes anything. Use destructiveChanges.xml (or the Pre and Post variants from API 33.0) for removals.
  • A retrieve fails if a named component does not exist in the source org, so generated manifests are safer than hand-typed ones.

See the full Project Manifest entry

Project Manifest includes the definition, worked example, deep dive, related terms, and a quiz.