A deployment in Salesforce is the act of moving metadata — the configuration and code that defines how an org works — from one org to another. Apex classes, custom objects, fields, flows, validation rules, page layouts, permission sets, and so on.
Note the precise word: metadata, not data. Data (records) moves through tools like Data Loader. Metadata moves through deployments.
Why deployments exist
You don’t build in production. You build in a sandbox — a configurable copy of production — then deploy the validated changes to production once they’re ready. That separation gives you:
- A safe place to break things.
- A path for unit tests and QA review.
- The ability to roll back code by re-deploying a known-good version.
- Compliance with the platform rule that all Apex code in production must pass tests with at least 75% coverage.
What gets deployed
Anything Salesforce represents as metadata. The full list is huge; the common items:
- Apex — classes, triggers, test classes
- Lightning Web Components / Aura Components
- Custom objects, fields, record types, validation rules
- Flows and processes
- Permission sets, profiles, sharing rules
- Page layouts, Lightning record pages
- Reports, dashboards, list views (with caveats)
- Email templates, email alerts
- Static resources
- Custom settings and custom metadata types
Records (Account rows, Contact rows) aren’t metadata — they don’t deploy.
The tools
| Tool | Best for |
|---|---|
| Change Sets | Admin-friendly, sandbox → connected production deployment via the UI |
| Salesforce DX (sf CLI) | Modern developer workflow, source-driven, Git-backed |
| Workbench | Quick deploys, package.xml retrieval, ad hoc API testing |
| Ant Migration Tool | Legacy CI, scriptable, declining but still in use |
| Metadata API | The protocol under everything else; custom scripts |
| 2GP / Unlocked / Managed Packages | Distributing change between orgs not connected by trust |
| AppExchange | ISV-style managed package install |
| Copado, Gearset, Flosum, Salto, AutoRABIT | Commercial DevOps platforms layered on Metadata API |
See What are different tools used for salesforce deployments? for the deep dive.
The basic deployment flow
- Build in a sandbox. Customise, code, configure.
- Test in the sandbox — unit tests, UAT.
- Package the changes as a change set, unlocked package, or
package.xmlmanifest + source. - Validate against the target org (Salesforce calls this a validation deployment — runs tests but doesn’t write changes).
- Deploy for real, or Quick Deploy the validated bundle if it ran tests in the last 10 days.
- Verify in production — smoke tests, monitor errors.
Rules production enforces
- 75% Apex code coverage across the org.
- Every test must pass.
- Production deploys run tests unless you Quick Deploy from a recent validation.
- Some metadata can’t be moved by change set (e.g. some standard list views, certain reports filters). The CLI / Metadata API handles more types.
Common reasons deploys fail
- Code coverage drops below 75%.
- A test class throws an unhandled exception.
- A dependent component wasn’t included (e.g. a field referenced by Apex but missing from the deployment).
- Profile / permission set changes reference components that don’t exist in the target.
- A validation rule references a field that doesn’t exist yet in the target.
Verified against: Salesforce DX Developer Guide, Metadata API Developer Guide. Last reviewed 2026-05-17 for Spring ‘26 release.