Short answer
Every Salesforce change should be built in a sandbox, tracked in source control, tested by someone other than the builder, approved by the business owner and deployed with a rollback plan. Use DevOps Center or the Salesforce CLI with a Git repository instead of change sets once more than one person is building.
Pick the deployment method
| Method | Fits | Watch out for |
|---|---|---|
| Change sets | One admin, small changes, no source control yet | No version history, no easy rollback, manual component picking |
| DevOps Center | Admin-led teams that want Git without the command line | Needs a GitHub repository and some setup discipline |
| Salesforce CLI and Git | Developers, integrations, Apex and LWC work, CI pipelines | Needs people comfortable with the command line |
Before the release
- Each change is tied to a ticket with the business reason and the requester.
- The change is in source control and peer reviewed.
- Apex tests pass and code coverage meets Salesforce's 75% minimum for production; aim higher for anything that touches client data.
- A tester other than the builder has signed off in QA, and the business owner has signed off in UAT.
- Profiles, permission sets and field-level security for new fields are part of the package.
- A rollback plan exists: the previous version in Git, or written steps to undo the change.
Release day
- Run a validation-only deployment to production first; it runs tests without committing.
- Deploy in an agreed window and tell users.
- Run the post-deployment steps (data updates, permission assignments, scheduled jobs).
- Smoke test the main user paths with a real user profile, not an admin.
After the release
- Record what was deployed, when and by whom. For regulated firms this change log is part of your evidence for system controls.
- Watch error emails, failed flows and integration logs for 48 hours.
Official documentation
Frequently asked questions
What code coverage does Salesforce require to deploy to production?
At least 75% of Apex code must be covered by passing tests across the org, and every trigger needs some coverage. Treat 75% as the floor, not the goal.
Should we stop using change sets?
Change sets are fine for a single admin making small changes. Once several people build at once, or you need version history and rollback, move to DevOps Center or the Salesforce CLI with Git.
Salesforce, HubSpot, Anthropic and OpenAI change their products often. Check the official documentation before you rely on a specific setting, limit or price.