The Sandbox That Time Forgot: Why Your Test Environment Is Lying to You
How to set up sandbox management that prevents production disasters
If your sandbox was last refreshed when your current admin's predecessor's predecessor was still employed, you don't have a sandbox. You have a museum.
A client deployed a Flow directly to production last year because "it was just a small update." The Flow updated the Account Owner field based on a region assignment rule. The logic was correct. The filter was not. Instead of updating Accounts in the "West" region, the Flow updated every Account in the org. 1,200 Account owners changed in 14 seconds.
The admin discovered the problem when the VP of Sales called her. His entire team had lost access to their Accounts because the ownership transfer changed the sharing permissions. Reps couldn't see their own pipeline. Customer-facing dashboards showed the wrong rep names. Automated emails went to the wrong Account owners. The cascade lasted 6 hours.
The fix: export the Account ownership data from a backup, match it against the current state, and mass-update 1,200 records. Total time: 6 hours of emergency work on a Friday night. Total cost: $3,000 in consulting fees plus the productivity loss across the sales team for half a day.
The admin had a sandbox. She hadn't refreshed it in 11 months. The sandbox didn't have the region field she was referencing because it was created after the last refresh. She tested the Flow in sandbox, it worked, and she deployed it. The Flow worked perfectly in sandbox. It broke production because the sandbox was a different org.
Testing in production is free until it isn't. Testing in a stale sandbox is the same thing with extra steps.
Why Sandbox Discipline Breaks Down
"We Don't Have Time to Refresh"
A sandbox refresh can take anywhere from 5 minutes (Developer sandbox) to several hours (Full sandbox). Admins who are buried in support tickets and stakeholder requests deprioritize the refresh because it doesn't have a deadline attached to it. The refresh gets pushed to "next week" indefinitely.
"The Sandbox Is Good Enough"
If the sandbox works for the test at hand, the admin deploys without checking whether the metadata is current. The sandbox might be missing 6 months of new fields, objects, Flows, and validation rules. The test passes in sandbox because the conditions that would cause failure in production don't exist in the sandbox.
"We Test in Production Because It's Faster"
Some orgs don't use sandboxes at all. Every change goes directly to production. The admin tests by watching whether users report problems. This works until it doesn't, and when it doesn't, the failure is visible to every user simultaneously.
"I Don't Know How to Refresh"
Junior admins sometimes aren't trained on sandbox management. They know sandboxes exist but don't know how to refresh them, how to handle login credentials after refresh, or how to manage sandbox-specific configurations.
Sandbox License Limitations
Some Salesforce editions include only Developer sandboxes (no data, metadata only). Others include Partial Copy sandboxes (subset of data). Admins who only have Developer sandboxes can't test data-dependent automations because there's no data to test against. This limitation pushes them toward production testing.
How to Set Up Proper Sandbox Architecture
The right sandbox architecture depends on your org's size and complexity. Here's the minimum for each tier.
For Orgs with 1-50 Users
Minimum: 1 Developer sandbox, refreshed monthly.
This covers basic configuration changes, Flow development, and page layout modifications. Test with sample data created manually in the sandbox.
For Orgs with 50-200 Users
Minimum: 1 Developer sandbox + 1 Partial Copy sandbox.
The Developer sandbox handles daily admin work and Flow development. The Partial Copy sandbox handles UAT (User Acceptance Testing) with a subset of real production data. Refresh the Developer sandbox monthly. Refresh the Partial Copy sandbox quarterly.
For Orgs with 200+ Users
Minimum: 2 Developer sandboxes + 1 Partial Copy sandbox + 1 Full sandbox.
Developer sandboxes handle parallel development work (two admins or developers working simultaneously). The Partial Copy sandbox handles UAT. The Full sandbox handles performance testing, data migration testing, and integration testing. Refresh Developer sandboxes monthly. Refresh Partial Copy quarterly. Refresh Full sandbox before major releases.
How to Refresh a Sandbox
Navigate to: Setup → Sandboxes → click "Refresh" next to the sandbox name
Before refreshing:
- Notify anyone currently working in the sandbox
- Export any configurations from the sandbox that haven't been deployed to production (they will be overwritten)
- Note any sandbox-specific configurations (test email addresses, integration endpoints) that need to be reconfigured after refresh
After refreshing:
- Login credentials: your sandbox login is your production username with ".sandboxname" appended. Example: jcarmona@ccc.com.devbox. The password is the same as production unless the admin has changed it.
- Configure sandbox-specific settings: update email deliverability (set to "System Email Only" to prevent sandbox actions from sending real emails to customers)
- Verify that custom metadata, custom settings, and named credentials are configured for sandbox use
Navigate to: Setup → Email → Deliverability → set Access Level to "System Email Only"
This is the most commonly missed step after a sandbox refresh. If you leave email deliverability at "All Email," your sandbox tests will send real emails to real customers.
The Deployment Process: Sandbox to Production
Every change follows this path: Build in sandbox → Test in sandbox → Deploy to production → Smoke test in production.
Step 1: Build in Sandbox
Make your configuration change, build your Flow, create your validation rule in the sandbox. Do not touch production.
Step 2: Test in Sandbox
Test with multiple scenarios:
- The happy path (the scenario you're designing for)
- The edge case (what happens with unusual data?)
- The null case (what happens when required fields are empty?)
- The bulk case (what happens when 200 records are updated simultaneously via data import?)
Document your test results. Screenshot the test data and the outcomes. This documentation becomes your evidence that the change was tested before deployment.
Step 3: Deploy to Production
For declarative changes (Flows, validation rules, page layouts, fields):
Navigate to: Setup → Outbound Change Sets (in sandbox)
Create a new change set. Add the components you're deploying. Upload the change set to production.
In production: Navigate to: Setup → Inbound Change Sets → find your change set → Validate (this checks for errors without deploying) → Deploy.
Always validate before deploying. Validation catches dependency errors, missing components, and API version mismatches before they affect production.
For code changes (Apex, Lightning Web Components):
Use Salesforce CLI (sf project deploy start) or VS Code with the Salesforce Extensions pack. These tools allow you to deploy specific metadata components and run tests as part of the deployment.
Step 4: Smoke Test in Production
After deployment, verify that the change works as expected in production. Check the specific scenario you built for. Check one edge case. Check that existing functionality wasn't broken by the new deployment.
If something breaks: revert. For Flows, deactivate the new version and reactivate the previous version. For code, redeploy the previous version from version control. For configuration changes, undo manually.
The Change Log: Documenting Every Deployment
Every deployment to production should be recorded in a change log. The log doesn't need to be complex. A shared spreadsheet with these columns:
| Column | Description |
|---|---|
| Date | Deployment date |
| Deployed By | Admin or developer name |
| Change Description | What was changed, in plain English |
| Components | Specific Flows, fields, objects, or code files deployed |
| Change Set Name | For declarative deployments |
| Test Evidence | Link to test screenshots or documentation |
| Rollback Plan | How to undo if something breaks |
This log serves two purposes. First, it creates a history that future admins can reference. When the next admin inherits the org, the change log tells them what happened, when, and why. Second, it supports troubleshooting. When something breaks in production, the change log tells you what changed recently, which narrows the diagnosis.
How to Prevent Production Disasters
Sandbox refresh calendar: Set a recurring calendar event for sandbox refreshes. Monthly for Developer sandboxes. Quarterly for Partial Copy. The calendar event includes a link to the refresh instructions and a checklist for post-refresh configuration.
Email deliverability check: Add "Verify email deliverability is set to System Email Only" to every post-refresh checklist. This single check prevents the most common sandbox mistake: accidentally emailing customers from a test environment.
No direct production changes policy: Establish and enforce a policy that no configuration changes are made directly in production. Every change goes through sandbox first. The only exception: emergency fixes to production-down issues, and those must be documented in the change log with a note explaining why the sandbox path was skipped.
Deploy during low-traffic windows: Schedule production deployments for early morning or Friday evening when user activity is lowest. If the deployment causes issues, the impact affects fewer users and gives you more time to troubleshoot before the next business day.
Change set naming convention: Name every change set with a date and description: YYYY-MM-DD_ShortDescription. Example: 2026-04-15_AccountOwnerFlow. This makes it easy to find specific deployments in the change set history.
Download the Sandbox Management Guide
The Sandbox Management Guide is a two-page PDF covering the minimum sandbox architecture for each org size tier, refresh schedules, post-refresh configuration checklist, deployment process steps, and a change log template. Print the post-refresh checklist and keep it next to your monitor.
Download it below. It's free.
Part 5 of 10 in the series: What Your Salesforce Org Says About Your Company.
