Salesforce Sandboxes are powerful tools for development and testing, they come with a few limitations that developers and administrators should be aware of. Understanding these sandbox limitations can help you better plan your deployment and testing strategy.
Sandbox Limitations
| Limitation | Description |
|---|---|
| Refresh Intervals | – Developer & Developer Pro: Once per day. – Partial Copy: Every 5 days. – Full Sandbox: Every 29 days. Limits on refresh interval can cause delays in accessing the latest production data. |
| Storage and Data Limits | – Developer: 200 MB data and files. – Developer Pro: 1 GB data and files. – Partial Copy: 5 GB data (sample data). Limits restrict comprehensive testing due to limited data access. |
| Data Masking | – Sensitive data is copied in Full and Partial Copy sandboxes without masking. Manual masking is needed to ensure data privacy and regulatory compliance. |
| Limited Sandbox Types Per Org | – Limited number of sandboxes based on Salesforce edition. Additional sandboxes may need to be purchased, which could increase costs. |
| Copying Data Takes Time | – Full Sandboxes can take hours or days to create, delaying testing activities. – Partial Copy also takes significant time to prepare. |
| Email and Integration Restrictions | – Outbound emails are disabled or redirected by default to prevent accidental blasts. External integrations may need reconfiguration within the sandbox environment. |
| No Real-Time Synchronization | – Sandboxes do not sync with production in real-time. Any new production changes after sandbox creation won’t be reflected until the sandbox is refreshed. |
| Licenses and User Access | – Not all production users have automatic access to sandboxes. – User licenses count against your total Salesforce license limit. |
| API Limitations | – API limits are lower in sandboxes compared to production environments. Heavy integration tests can sometimes hit these limits, especially in Developer sandboxes. |
| Deployment Code Coverage | – Deployments require a minimum code coverage of 75%. This requirement can delay the deployment process if proper test coverage isn’t met. |
| Testing Data Differences | – Limited data in Developer and Developer Pro sandboxes can lead to inadequate testing. Lack of real-world data might make it difficult to replicate production issues. |
| Dependency on Sandbox Refresh for Metadata | – Metadata changes in production are not reflected in sandboxes unless they are refreshed. This can lead to discrepancies between sandbox and production environments. |
1. Following table describes Sandbox Storage limits
| Sandbox Type | Storage Limit |
| Developer Sandbox | 200 MB |
| Developer Pro Sandbox | 1 GB |
| Partial Data Sandbox | 5 GB and maximum 10,000 record per selected object. |
| Full Copy | Same Storage limits as your production organization. |
To know about storage usage in your organization follow below steps.
Setup -> data management -> click on storage usage.
2. Sandbox refreshing limits
| Sandbox Type | You can refresh |
| Developer Sandbox | Once per day |
| Developer Pro Sandbox | Once per day |
| Partial Data Sandbox | You can refresh a Partial Data sandbox 5 days after you created or last refreshed it. If you delete a Partial Data sandbox within those 5 days, you need to wait until after the 5 day period, from the date of last refresh or creation, to replace it. |
| Full copy Sandbox | You can refresh a Full sandbox 29 days after you created or last refreshed it. If you delete a Full sandbox within those 29 days, you need to wait until after the 29 day period, from the date of last refresh or creation, to replace it. |