A Salesforce sandbox creates an exact copy of your production organization in a separate environment for development and testing. This Salesforce tutorial covers sandbox types, deployment strategies, and best practices for developers and administrators working with sandbox environments.
What is a Salesforce Sandbox?
A sandbox creates an exact copy of your production organization’s metadata in a separate environment. This allows developers and administrators to develop and test customizations without affecting production data. Sandboxes replicate your org’s configuration, custom objects, fields, workflows, and Apex code while maintaining complete isolation from live data.
When to Use Salesforce Sandboxes
Use sandboxes for high-risk customizations that could impact production stability:
- Custom applications and Lightning components
- Custom tabs and page layouts
- Workflow rules and Process Builder flows
- Validation rules with complex logic
- Connected apps and API integrations
- Custom objects, fields, and relationships
- Apex classes and triggers
- Lightning Web Components and Visualforce pages
- Permission sets and security model changes
When Sandboxes Are Not Required
Simple configurations can often be done directly in production with proper testing:
- Reports and dashboards (unless complex)
- Email templates
- Folders and list views
- Basic field updates
- Simple workflow email alerts
Salesforce Sandbox Types and Features
Salesforce provides four sandbox types, each designed for different development and testing scenarios. Choose based on your data requirements, team size, and testing complexity.
Developer Sandbox
Developer sandboxes are designed for individual developers working on code and configuration changes.
Developer Sandbox Features:
- Storage: 200 MB data storage limit
- Refresh frequency: Daily refresh available
- Metadata: Includes all applications and configuration
- Data: No production data included
- Use case: Individual development and unit testing
- API version: Matches production org’s API version
Developer Pro Sandbox
Developer Pro sandboxes provide more storage for larger development teams and complex applications.
Developer Pro Sandbox Features:
- Storage: 1 GB data storage capacity
- Refresh frequency: Daily refresh available
- Metadata: Complete metadata copy from production
- Data: No production data included
- Use case: Team development and integration testing
- Performance: Better suited for larger codebases
Partial Copy Sandbox
Partial Copy sandboxes include selected production data for realistic testing scenarios.
Partial Copy Sandbox Features:
- Storage: 5 GB data storage capacity
- Record limit: 10,000 records per object maximum
- Refresh frequency: Every 5 days
- Data selection: Use sandbox templates to specify which data to include
- Use case: User acceptance testing with realistic data
- Data masking: Consider data privacy requirements
Full Copy Sandbox
Full Copy sandboxes replicate your entire production environment, including all data and attachments.
Full Copy Sandbox Features:
- Storage: Same capacity as production organization
- Refresh frequency: Every 29 days
- Data: Complete copy of production data
- Records: Maintains same record IDs as production
- Attachments: Includes documents and files
- Use case: Performance testing, training, and final UAT
Salesforce Sandbox Migration Tools
Deploy changes from sandbox to production using these migration tools, each suited for different deployment scenarios.
Change Sets
Change sets provide a point-and-click deployment method through the Salesforce UI.
- Best for: Declarative customizations and simple deployments
- Limitations: Cannot deploy all metadata types
- Validation: Supports validation-only deployments
Salesforce CLI and VS Code
Modern development workflow using Salesforce CLI and Visual Studio Code.
- Best for: Apex development and complex deployments
- Version control: Integrates with Git repositories
- Automation: Supports CI/CD pipelines
Ant Migration Tool
Command-line tool for automated deployments and large-scale migrations.
- Best for: Automated deployments and DevOps workflows
- Flexibility: Handles complex deployment scenarios
- Integration: Works with build automation tools
Salesforce Sandbox Best Practices
Follow these deployment best practices to ensure successful sandbox-to-production migrations:
Development Best Practices
- Test thoroughly: Validate all customizations before deployment
- Code coverage: Ensure 75% minimum test coverage for Apex code
- Bulk testing: Test with realistic data volumes
- User acceptance: Involve business users in testing process
- Rollback plan: Prepare rollback procedures for critical deployments
Deployment Strategy
- Validation deployment: Always run validation-only deployments first
- Maintenance window: Schedule deployments during low-usage periods
- Incremental deployment: Deploy in smaller, manageable chunks
- Monitor governor limits: Check CPU time, SOQL queries, and DML statements
Security Considerations
- Data masking: Mask sensitive data in sandboxes
- User access: Limit sandbox access to authorized personnel
- Integration endpoints: Use sandbox-specific endpoints for external systems
- Email deliverability: Disable email delivery in sandboxes to prevent accidental sends
Common Salesforce Sandbox Interview Questions
Prepare for Salesforce admin and developer interviews with these key sandbox concepts:
Technical Questions
- Sandbox refresh impact: How refreshing affects existing data and customizations
- Deployment limitations: Which metadata types cannot be deployed via change sets
- Governor limits: How sandbox limits differ from production
- Integration patterns: Best practices for sandbox-to-production integrations
Security and Relationships
- Object relationships: How master-detail and lookup relationships behave in sandboxes
- Sharing rules: Impact of organization-wide defaults in sandbox environments
- Profile and permission sets: Security model considerations during deployment
Accessing Your Salesforce Sandbox
Access your sandbox environment through the dedicated login URL: https://test.salesforce.com
Use your production username with the sandbox name appended (e.g., username@company.com.sandboxname) and your production password.
Frequently Asked Questions
What happens to my sandbox data when I refresh it?
Refreshing a sandbox overwrites all existing data and metadata with the current production configuration. Any customizations made only in the sandbox will be lost unless they were deployed to production first.
Can I deploy Apex code without test classes in a sandbox?
You can save Apex code without test classes in a sandbox, but deployment to production requires 75% minimum test coverage. Write comprehensive test classes in your sandbox before attempting deployment.
How do I handle external integrations in sandbox environments?
Use separate sandbox endpoints for external systems to avoid impacting production integrations. Configure named credentials and remote site settings specific to your sandbox environment, and ensure external systems can differentiate between sandbox and production calls.
What’s the difference between validation and deployment in change sets?
Validation checks if your changes can be deployed successfully without actually making the changes. Deployment applies the changes to the target org. Always run validation first to identify potential issues before deploying to production.
Can I create custom objects in a Developer sandbox?
Yes, you can create custom objects, fields, and relationships in any sandbox type. Developer sandboxes include full metadata capabilities, allowing you to build and test custom applications before deploying to production.