Metadata Components are the unit of work in any Salesforce deployment. The day-to-day workflow uses SFDX CLI and source-format projects.
- Retrieve components from an org
Run sf project retrieve start -m ApexClass:MyClass -m CustomObject:Account -o my-org. The CLI pulls the listed components into the local project in source format.
- Edit in VS Code
Open the SFDX project. Edit the component source files. The Salesforce Extensions Pack provides syntax highlighting, validation, and IntelliSense.
- Deploy to an org
Run sf project deploy start -m ApexClass:MyClass -o my-org. The CLI deploys the listed components. Use -x manifest/package.xml for larger sets.
- Version-control with git
Commit changes to git. Open pull requests. The SFDX source format produces clean diffs at the file level.
- Check the Metadata Coverage Report
Before assuming a configuration can be deployed, verify the component type is supported by the Metadata API.
- Build CI/CD pipelines
Modern pipelines (Copado, AutoRabit, Gearset, GitHub Actions) generate manifest files from git diffs and deploy automatically.
- Not every configuration is API-supported. Check the Metadata Coverage Report before planning a migration.
- Source format and metadata format are different. Modern tools default to source format; legacy projects may need conversion.
- Deployments may fail due to dependencies. Component A may require component B; deploying out of order fails. Group related components in the same manifest.
- Some metadata types behave differently in managed packages. Test before relying on cross-org package deployments.