Salesforce Sandbox Guide: Types, Best Practices & Setup
Salesforce Sandbox Guide
A Salesforce sandbox is a separate copy of your Salesforce environment used for development, testing, training, and experimentation without affecting live production data or business processes. This Salesforce sandbox guide explains what sandboxes are, the different sandbox types, when to use each one, best practices for managing them, and how to build a reliable sandbox strategy for your organization.
For teams that rely on Salesforce as a core CRM, sandboxes are essential. They allow administrators, developers, consultants, and business users to test changes safely before deploying them to production. If your organization is still evaluating the broader value of the platform, this overview of why businesses choose Salesforce CRM explains many of the platform strengths that make sandbox governance so important.
What Is a Salesforce Sandbox?
A Salesforce sandbox is a non-production environment that replicates some or all of your Salesforce production org. Depending on the sandbox type, it may include metadata, configuration, code, automation, and a sample or full copy of production data.
In simple terms, production is where real users work with real customer data, while a sandbox is where teams can safely build, test, and validate changes. Sandboxes are commonly used for:
- Testing new fields, objects, page layouts, flows, validation rules, and automations
- Developing and reviewing Apex code, Lightning Web Components, and integrations
- Training users without exposing live customer or sales data
- Testing releases, managed packages, and third-party applications
- Validating data migrations and large configuration changes
- Running user acceptance testing before deployment
Why Salesforce Sandboxes Matter
Salesforce is often connected to critical sales, service, marketing, finance, and operational processes. Even a small configuration change can affect lead routing, opportunity management, reporting, approvals, or integrations. Sandboxes reduce risk by creating a controlled place to test before changes reach production.
They Protect Production Data
Production data is valuable and sensitive. Testing directly in production can create duplicate records, trigger unwanted emails, break reports, or expose customer information to users who do not need it. A sandbox gives teams a safer environment for experimentation.
They Improve Release Quality
Sandbox testing helps identify errors before deployment. Admins and developers can validate business logic, automation paths, field dependencies, sharing rules, and integrations. This leads to cleaner releases and fewer emergency fixes.
They Support Collaboration
Multiple teams often work on Salesforce at the same time. A structured sandbox approach helps developers, admins, testers, and business stakeholders collaborate without interfering with one another’s work.
They Enable Better Training
Training users in production is risky. A sandbox lets sales reps, service agents, and managers practice real processes in a safe space where mistakes do not affect live records or reports.
Salesforce Sandbox Types
Salesforce offers different sandbox types to support different use cases. The main sandbox types are Developer, Developer Pro, Partial Copy, and Full Sandbox. Each type has different storage limits, refresh intervals, and data-copying capabilities.
1. Developer Sandbox
A Developer Sandbox is designed for individual development and configuration work. It copies your production metadata but does not include production data by default.
Best for:
- Building new fields, objects, flows, and validation rules
- Developing Apex and Lightning components
- Testing small configuration changes
- Isolated admin or developer work
Key characteristics:
- Includes metadata and configuration
- Limited data and file storage
- Can be refreshed frequently
- Useful for individual development tasks
2. Developer Pro Sandbox
A Developer Pro Sandbox is similar to a Developer Sandbox but provides more storage. It is useful when teams need a larger test data set or more room for development and quality assurance activities.
Best for:
- More complex development work
- Testing with larger sample data sets
- Admin configuration and QA testing
- Multiple related development tasks
Key characteristics:
- Includes metadata and configuration
- More storage than a Developer Sandbox
- Good for testing more complex scenarios
- Can be refreshed more often than Partial or Full Sandboxes
3. Partial Copy Sandbox
A Partial Copy Sandbox includes your production metadata and a sample of production data based on a sandbox template. This makes it useful for testing business processes that require realistic data without copying the entire production database.
Best for:
- User acceptance testing
- Testing automations with representative data
- Integration testing with selected objects
- Training scenarios that require sample records
Key characteristics:
- Includes metadata and selected production data
- Uses sandbox templates to define copied objects
- More realistic than Developer sandboxes
- Refresh interval is longer than Developer sandboxes
4. Full Sandbox
A Full Sandbox is a complete copy of your production environment, including metadata, records, attachments, and files. It is the most production-like sandbox type and is typically used for performance testing, final release testing, data migration testing, and full user acceptance testing.
Best for:
- End-to-end regression testing
- Performance and load testing
- Testing large data migrations
- Final pre-production validation
- Complex integration testing
Key characteristics:
- Copies all metadata and production data
- Most realistic testing environment
- Requires careful security and data protection controls
- Has the longest refresh interval
Salesforce Sandbox Comparison
The right sandbox depends on the type of work being performed. A Developer Sandbox is usually enough for small configuration or code changes, while a Full Sandbox is better for testing critical releases against production-like data.
| Sandbox Type | Includes Metadata | Includes Production Data | Common Use Case |
|---|---|---|---|
| Developer | Yes | No, except manually added test data | Individual development and configuration |
| Developer Pro | Yes | No, except manually added test data | Larger development and QA tasks |
| Partial Copy | Yes | Selected sample data | User acceptance testing and realistic process testing |
| Full | Yes | Yes, full production copy | Final release testing, migration testing, and performance testing |
Common Salesforce Sandbox Use Cases
Development
Developers use sandboxes to build Apex classes, triggers, Lightning Web Components, integrations, and custom logic. Admins also use sandboxes to configure flows, validation rules, approval processes, and page layouts before moving them to production.
Quality Assurance Testing
QA teams test whether new changes behave as expected. This includes positive testing, negative testing, regression testing, permission testing, and cross-object process validation.
User Acceptance Testing
User acceptance testing, often called UAT, allows business users to confirm that Salesforce changes meet real operational requirements. A Partial Copy or Full Sandbox is often best for UAT because users can test against realistic records and scenarios.
Training
Training sandboxes are useful for onboarding new users or introducing new features. Users can create, update, and delete practice records without affecting actual customers, pipeline, cases, or dashboards.
Integration Testing
If Salesforce connects to ERP, marketing automation, billing, support, data warehouse, or external applications, sandboxes help teams test those integrations safely. Integration testing should verify authentication, field mapping, error handling, sync timing, and data volume behavior.
Data Migration Testing
Before importing or transforming large volumes of data, teams should test the migration process in a sandbox. This helps validate data quality, record ownership, duplicate rules, required fields, automation side effects, and reporting accuracy.
How to Create a Salesforce Sandbox
Creating a sandbox is usually handled by a Salesforce administrator or release manager with the correct permissions. The exact options available depend on your Salesforce edition and licenses.
- Go to Setup in Salesforce.
- Search for Sandboxes in the Quick Find box.
- Select Sandboxes.
- Click New Sandbox.
- Enter a sandbox name and description.
- Select the sandbox type, such as Developer, Developer Pro, Partial Copy, or Full.
- If using a Partial Copy or Full Sandbox, select or configure the appropriate sandbox template if needed.
- Click Create.
After creation, Salesforce begins copying metadata and, depending on the sandbox type, data. The time required can vary from minutes to many hours depending on org size, sandbox type, and system load.
What Is a Sandbox Template?
A sandbox template controls which objects and data are copied into a Partial Copy or Full Sandbox. Templates are especially useful for Partial Copy Sandboxes because they allow teams to define a representative data set rather than copying unnecessary records.
For example, a sales testing sandbox might include Accounts, Contacts, Leads, Opportunities, Products, Quotes, and related custom objects. A service testing sandbox might include Accounts, Contacts, Cases, Entitlements, Assets, and Knowledge-related objects.
How Sandbox Refresh Works
Refreshing a sandbox replaces its existing contents with a new copy from production. This is useful when the sandbox needs up-to-date metadata or data, but it should be planned carefully because a refresh deletes work that exists only in the sandbox.
Before refreshing a sandbox, teams should:
- Confirm that all required changes have been deployed or backed up
- Notify users, developers, and testers
- Export important test data if needed
- Review integrations connected to the sandbox
- Deactivate jobs or automation that should not run after refresh
- Reapply environment-specific settings after refresh
Salesforce Sandbox Best Practices
1. Use a Clear Sandbox Strategy
Every sandbox should have a defined purpose. Avoid creating sandboxes without ownership or governance. A strong sandbox strategy may include separate environments for development, integration testing, UAT, staging, and training.
2. Name Sandboxes Consistently
Use clear names that describe each sandbox’s purpose. Examples include:
- DEV_ADMIN
- DEV_APEX
- QA
- UAT
- STAGING
- TRAINING
Consistent naming helps teams understand where work should happen and reduces the chance of testing or deploying from the wrong environment.
3. Protect Sensitive Data
Full and Partial Copy Sandboxes may contain sensitive customer, employee, financial, or operational data. Limit access to users who need it and consider masking or anonymizing sensitive fields where appropriate.
Data protection is especially important when consultants, contractors, developers, or external vendors need sandbox access. Use the principle of least privilege and review access regularly.
4. Disable Unwanted Email Deliverability
After a sandbox refresh, check email deliverability settings. You do not want test automations, workflows, flows, Apex jobs, or user actions sending real emails to customers or partners from a sandbox.
5. Update Integration Endpoints
Sandboxes should not accidentally connect to live production systems unless intentionally designed for that purpose. After a refresh, verify connected apps, named credentials, remote site settings, middleware connections, API credentials, and endpoint URLs.
6. Seed Test Data Properly
Developer sandboxes usually need manually created or imported test data. Use realistic test records that represent actual business scenarios, including edge cases. Good test data improves the quality of testing and reduces missed defects.
7. Document Environment Differences
Not every sandbox will match production exactly. Document differences in data, integrations, users, permissions, feature settings, scheduled jobs, and connected applications. This makes troubleshooting easier and helps testers understand limitations.
8. Keep Sandboxes Clean
Old test records, abandoned metadata, inactive users, and unfinished experiments can make a sandbox confusing. Periodically clean up sandboxes or refresh them from production to maintain reliability.
9. Control Deployments
Do not let every sandbox deploy directly to production. Use a controlled release path, such as development to QA, QA to UAT, UAT to staging, and staging to production. This improves traceability and reduces deployment risk.
10. Track Changes
Maintain a record of what is being built, tested, approved, and deployed. Teams commonly use user stories, tickets, change sets, Salesforce DevOps Center, source control, or third-party DevOps tools to manage changes.
Recommended Salesforce Sandbox Architecture
The ideal sandbox architecture depends on complexity, team size, release frequency, and compliance requirements. A small organization may only need one Developer Sandbox and one UAT sandbox. A larger enterprise may need multiple development sandboxes, integration environments, QA, UAT, staging, and training sandboxes.
Simple Sandbox Model
A simple model works for smaller teams with limited customization:
- Developer Sandbox: Admin and developer configuration work
- Partial Copy Sandbox: UAT and business process testing
- Production: Live environment
Standard Sandbox Model
A standard model works for growing organizations with regular releases:
- Developer Sandboxes: Individual admin and developer work
- QA Sandbox: Functional and regression testing
- UAT Sandbox: Business user validation
- Production: Live environment
Enterprise Sandbox Model
An enterprise model works for complex Salesforce environments:
- Developer Sandboxes: Individual feature development
- Integration Sandbox: Merged development changes and integration testing
- QA Sandbox: Formal testing
- UAT Sandbox: Business approval
- Staging or Full Sandbox: Final production-like validation
- Training Sandbox: End-user practice and enablement
- Production: Live environment
Salesforce Sandbox Deployment Options
After changes are built and tested in a sandbox, they must be moved to production. Salesforce supports several deployment approaches.
Change Sets
Change sets are a native Salesforce deployment tool used to move metadata between connected orgs. They are suitable for many admin-driven changes but can be limited for complex development pipelines.
Salesforce CLI
Salesforce CLI is commonly used by developers to retrieve, deploy, validate, and manage metadata. It is especially useful when combined with source control and automated pipelines.
DevOps Center
Salesforce DevOps Center helps teams manage changes with a more modern, source-driven approach. It is designed to provide better visibility across work items, environments, and deployments.
Third-Party DevOps Tools
Many organizations use third-party Salesforce DevOps platforms for advanced release management, version control, automated testing, rollback support, compliance controls, and deployment comparison.
Common Salesforce Sandbox Mistakes
Testing Only Happy Paths
Teams often test only ideal scenarios. Strong sandbox testing should include error conditions, missing data, permission restrictions, duplicate records, integration failures, and unusual business cases.
Refreshing Without Backup
A refresh permanently replaces the existing sandbox. If metadata or data has not been moved or backed up, work may be lost. Always confirm before refreshing.
Using Production Integrations by Accident
A sandbox connected to live production systems can create major data issues. Always review endpoints, credentials, scheduled jobs, and API connections after sandbox creation or refresh.
Ignoring Permissions
Testing as a system administrator is not enough. Business users may have different profiles, permission sets, sharing access, page layouts, and field-level security. Test with realistic user permissions.
Letting Sandboxes Become Outdated
An outdated sandbox may not reflect current production metadata or business processes. Refresh sandboxes as part of a planned release cycle so testing remains meaningful.
Salesforce Sandbox Security Checklist
Use this checklist to improve sandbox security and reduce operational risk:
- Limit user access based on role and need
- Review active users after each refresh
- Mask or anonymize sensitive data when possible
- Disable unnecessary email sending
- Use sandbox-specific integration credentials
- Review connected apps and OAuth access
- Deactivate scheduled jobs that should not run
- Restrict external system connections
- Audit permission sets and profiles
- Document sandbox purpose and ownership
Salesforce Sandbox Testing Checklist
Before approving a change for production, confirm that testing covers the right scenarios:
- New and updated fields display correctly
- Validation rules work as expected
- Flows and automation run correctly
- Apex tests pass successfully
- Reports and dashboards still show accurate data
- Users with different profiles can complete their tasks
- Integrations send and receive expected data
- Email alerts and notifications are appropriate
- Mobile and desktop experiences are validated if relevant
- Regression testing confirms existing processes still work
How Often Should You Refresh a Salesforce Sandbox?
Sandbox refresh frequency depends on the sandbox type, project timeline, and testing needs. Development sandboxes may be refreshed frequently, while Full Sandboxes typically have longer refresh intervals and require more planning.
As a general rule:
- Developer sandboxes: Refresh when production metadata has changed significantly or when a clean environment is needed.
- Developer Pro sandboxes: Refresh before major QA cycles or when test data becomes unreliable.
- Partial Copy sandboxes: Refresh before UAT, training, or major process testing.
- Full sandboxes: Refresh before large releases, performance testing, migration testing, or final staging validation.
Who Should Own Salesforce Sandboxes?
Each sandbox should have a clear owner. Ownership may sit with a Salesforce administrator, platform manager, release manager, technical lead, or DevOps team. The owner is responsible for access, refresh planning, environment readiness, documentation, and coordination.
In larger organizations, sandbox governance may be managed by a Salesforce Center of Excellence. This group defines standards for development, testing, releases, security, and platform architecture.
Salesforce Sandbox FAQs
Is a Salesforce sandbox the same as production?
No. A sandbox is a separate non-production environment. Some sandboxes closely resemble production, especially Full Sandboxes, but they are still separate environments used for testing, development, and training.
Can users log in to a Salesforce sandbox?
Yes. Users can log in to sandboxes, usually with a modified username that includes the sandbox name. Access depends on whether the user exists in the sandbox and whether they are active.
Does a Salesforce sandbox contain real data?
It depends on the sandbox type. Developer and Developer Pro Sandboxes generally include metadata but not production data. Partial Copy Sandboxes include selected sample data. Full Sandboxes include a complete copy of production data.
Can I delete a Salesforce sandbox?
Yes, sandboxes can be deleted if they are no longer needed. Before deleting one, confirm that all important metadata, data, and test results have been saved or moved elsewhere.
Can changes be made directly in production instead of a sandbox?
Some very small, low-risk changes may be made directly in production by experienced administrators, but it is generally safer to build and test changes in a sandbox first. For complex automation, code, integrations, permissions, or data changes, sandbox testing is strongly recommended.
Which Salesforce sandbox is best for UAT?
A Partial Copy Sandbox is often a good fit for UAT because it includes representative production data. For highly complex or business-critical testing, a Full Sandbox may be better because it provides the most production-like environment.
Conclusion
A well-managed Salesforce sandbox strategy helps organizations develop faster, test more accurately, train users safely, and protect production from avoidable errors. The key is to choose the right sandbox type for each purpose, define clear ownership, protect sensitive data, and follow a structured release process.
Whether your team is making simple admin updates or managing enterprise-scale Salesforce development, sandboxes are a critical part of reliable platform management. By using the guidance in this Salesforce sandbox guide, you can reduce deployment risk, improve testing quality, and give your teams the confidence to innovate safely.
