Manifest files can be hand-written, generated by the Salesforce CLI, or produced by CI/CD pipelines. Most modern workflows use the CLI to generate them.
- Generate the manifest from a source folder
Run sf project generate manifest --source-dir force-app/main/default. The CLI scans the source and produces a package.xml.
- Or hand-write the package.xml
Create the file with the required XML structure: <Package xmlns=...><types><name>ApexClass</name><members>MyClass</members></types><version>60.0</version></Package>.
- Retrieve metadata using the manifest
Run sf project retrieve start -x manifest/package.xml -o my-org. The CLI pulls every component listed in the manifest.
- Deploy using the manifest
Run sf project deploy start -x manifest/package.xml -o my-org. The CLI deploys the listed components.
- Add destructiveChanges.xml for deletions
Create destructiveChanges.xml alongside package.xml with the components to delete. The CLI includes both in the deployment.
- Integrate with CI/CD
Set up the pipeline (Copado, AutoRabit, GitHub Actions) to generate manifests from git diffs and run deployments automatically.
The Salesforce API version the manifest targets.
Per metadata type with name and member list.
For deletions in the same deployment.
The tool that consumes the manifest.
- apiVersion mismatches cause deploy failures. Match the manifest version to the target org''s supported API version.
- Wildcards behave differently for retrieve vs. deploy. Wildcards are fine for retrieval; production deploys usually require explicit member lists.
- destructiveChanges.xml deletions run after adds and updates. The order matters for some metadata dependencies.
- Some metadata types are not supported by Metadata API. Check the Metadata Coverage Report before assuming a type can be manifested.