Key takeaways
- Build and test changes in sandboxes, never directly in production.
- Source control gives you history, review and rollback for metadata and code.
- DevOps Center offers a guided, point-and-click pipeline; the Salesforce CLI with a CI tool offers full flexibility.
- Start simple: one development sandbox, one testing sandbox, source control and a release checklist.
Many Salesforce orgs still change production directly: a new field here, an edited flow there. It works until a change breaks something important and nobody knows what changed or how to undo it. A basic DevOps process prevents that, and it does not have to be complicated.
Sandbox types
| Sandbox | What it contains | Typical use |
|---|---|---|
| Developer | Metadata only, small storage | Individual development and configuration |
| Developer Pro | Metadata only, more storage | Development needing more test data |
| Partial Copy | Metadata plus a sample of data | Testing with realistic data |
| Full | Metadata plus a full copy of data | Performance testing, staging and user acceptance |
Which sandboxes you get, and how many, depends on your edition and licenses. Scratch orgs, short-lived orgs created from source, are another option for development teams.
Why source control matters
- History: see what changed, when and by whom.
- Review: changes can be reviewed before they reach production.
- Rollback: return to a known good version if something breaks.
- Collaboration: several people can work without overwriting each other.
Release tools
| Tool | Strengths | Consider |
|---|---|---|
| Change sets | Built in, no extra tools | No version history, manual and error-prone at scale |
| DevOps Center | Salesforce’s guided pipeline with source control integration, friendly for admins | Best for teams adopting a structured but simple process |
| Salesforce CLI with CI/CD | Full automation, testing and flexibility | Requires developer skills to set up and maintain |
| Third-party DevOps platforms | Rich features, comparisons and rollback | Additional licensing |
A simple, reliable process
- Each change starts as a ticket with a clear description and acceptance criteria.
- Build in a development sandbox and commit to source control.
- Deploy to a testing sandbox; users test against the acceptance criteria.
- Run automated checks: Apex tests, validation deployment and code analysis where available.
- Deploy to production in a planned window, with release notes.
- Verify in production and close the ticket.
Testing essentials
- Apex code needs at least 75% test coverage to deploy to production, but meaningful assertions matter more than coverage.
- Test flows with realistic bulk data, not single records.
- Validate deployments before the release window to catch errors early.
- Refresh testing sandboxes regularly so they reflect production.
Common mistakes
- Sandboxes that drift far from production because they are never refreshed.
- Hot fixes in production that are never added to source control, so the next deployment overwrites them.
- Deploying large bundles of unrelated changes at once.
- No rollback plan for high-risk releases.
We help teams set up practical release processes as part of our administration and support services.
A release checklist
| Before | During | After |
|---|---|---|
| Changes tested and approved in a sandbox | Deploy in the agreed window | Smoke-test key processes |
| Validation deployment succeeded | Run Apex tests | Confirm automation and integrations behave |
| Release notes written | Apply manual post-deployment steps | Communicate changes to users |
| Rollback plan for risky changes | Monitor errors | Merge hot fixes back into source control |
Growing the process over time
Start with the basics and add automation as the team grows: automated validation on every change, code quality scanning, automated tests for key flows, and scheduled sandbox refreshes. The goal is not tooling for its own sake but fewer surprises in production and faster, safer delivery.
Frequently asked questions
Do admins need source control?
Admin changes are metadata too. Tools like DevOps Center make source control accessible to admins without command-line work.
What is the minimum setup for a small team?
A development sandbox, a testing sandbox or the same sandbox refreshed between releases, source control and a written release checklist.
Can we deploy flows with change sets?
Yes, but change sets lack version history and become hard to manage as change volume grows.
