Salesforce Sandboxes and Deployment

A chef tests a new recipe in a practice kitchen before serving it in the restaurant. A mistake in the practice kitchen costs nothing. A mistake in the dining room upsets customers. Salesforce sandboxes work as practice kitchens. They are copies of a production org where admins and developers build and test changes without touching live data or live users.

The Development Path

+-----------+    +---------+    +---------+    +------------+
| Developer | -> | Testing | -> | Staging | -> | Production |
| Sandbox   |    | Sandbox |    | Sandbox |    |   (live)   |
+-----------+    +---------+    +---------+    +------------+
  Build here      Test here     Final check     Users work here

Teams move changes along the path from left to right. Each stop catches a different kind of problem.

Sandbox Types

Type	Copies	Typical Use
Developer	Configuration and code only, with a small data limit	Individual building and unit testing
Developer Pro	Configuration and code with larger data storage	Heavier development and integration tests
Partial Copy	Configuration plus a sample of production data	User acceptance testing
Full	Complete copy of configuration and data	Performance tests and final rehearsal

Edition and licence decide how many sandboxes of each type an org owns. Storage sizes and refresh intervals vary, so check the current figures in Setup before planning.

Create a Sandbox

1. Open Setup in production and search for Sandboxes.
2. Click New Sandbox.
3. Enter a short name, such as dev1, and a description.
4. Select the type.
5. Choose a template or data sample when the type allows it.
6. Click Create and wait for the email that confirms completion.
7. Log in with the production username plus a dot and the sandbox name, for example admin@company.com.dev1.

Refreshing a Sandbox

A refresh replaces the sandbox with a fresh copy of production. Teams refresh to bring in new configuration and updated data. A refresh erases changes that were never deployed, so developers save their work first.

Ways to Deploy Changes

Change Sets

Change sets move metadata between connected orgs through the browser. The admin creates an outbound change set in the source org, adds components such as fields, flows, and classes, and uploads it to the target org. The target admin opens the inbound change set, validates it, and deploys. Change sets suit small teams and simple releases.

Source Sandbox                      Production
+--------------------+  upload  +----------------------+
| Outbound Change Set| -------> | Inbound Change Set   |
| - Custom field     |          | Validate > Deploy    |
| - Flow             |          +----------------------+
| - Apex class       |
+--------------------+

Salesforce CLI and Metadata API

Developers describe the components in a manifest file or a project folder and deploy with a command. Scripts make releases repeatable and fit into automated pipelines.

DevOps Center

DevOps Center gives teams a point-and-click workflow with version control behind it. Work items track each change from development to release.

Deployment Rules to Remember

• Apex code needs at least 75 percent test coverage across the org before deploying to production.
• Every trigger needs some coverage.
• Production runs the specified tests during a deployment, and any failure stops the release.
• Change sets do not carry every metadata type. Some items need manual setup after deployment.
• Users, passwords, and most data never travel in a deployment.

Validate Before You Deploy

A validation runs every check of a deployment without saving anything. Teams validate during the week and perform the quick deploy during a quiet window. Quick deploy reuses a recent successful validation and finishes in a short time.

Example Scenario: New Discount Approval

1. An admin builds the approval flow in a Developer sandbox.
2. A tester runs sample deals in the Partial Copy sandbox.
3. The product owner approves the behaviour.
4. The admin creates a change set and validates it in production.
5. The admin deploys on Friday evening and checks one real deal.

Best Practices

• Never build directly in production.
• Keep a release checklist that lists every component and manual step.
• Deploy small batches often instead of large releases rarely.
• Back up configuration with version control.
• Mask sensitive data in sandboxes that copy production records.
• Announce releases to users in advance.