Salesforce sandbox types: metadata, sample data and a safe test brief
Compare Salesforce sandbox types for configuration, sample data and full copies. Scope the test, records and connected services.
In this guide
A sandbox type describes what is copied
Salesforce’s sandbox guidance distinguishes Developer and Developer Pro copies of production configuration from Partial Copy environments with a selected data sample and Full environments that replicate production data and metadata. Availability depends on the organisation’s entitlements.
Start with the test you need to run. Configuring a field, rehearsing a sales process and measuring a production-scale workload are different activities. The word sandbox does not mean every available environment contains the same records, storage or capacity.
Choose the smallest representative data set
For an illustrative quote-approval project, a useful test set might contain fictional accounts, contacts, opportunities, products and one rejected approval. The team needs enough relationships to exercise the process; it does not automatically need the complete customer database.
Write down which entities are necessary and what would make the test invalid. A quotation with no product lines may be too small to expose the integration problem. A copy containing unrelated customers may add avoidable handling work. Have the data owner approve the proposed sample and how confidential values are treated.
Map the environment to the question
| Question | Environment requirement to assess | Acceptance evidence |
|---|---|---|
| Does a new field and rule work? | Required configuration and fictional records | Expected valid and invalid cases |
| Can staff complete the sales workflow? | Representative related records and user roles | Recorded handovers and exceptions |
| Does an integration behave correctly? | Authorised test endpoint and data contract | Received synthetic request and response |
| Can the workload meet its target? | Suitable scale and supported test environment | Measured result under stated conditions |
The table is a planning aid, not a claim that a particular organisation owns the required sandbox licences. Confirm the exact type and permitted test scope before scheduling the work.
A copied integration needs a destination review
List outbound email, payment services, webhooks, external storage and scheduled jobs in the rehearsal brief. Identify which are disabled, redirected to an authorised test service or explicitly part of the test. Give each connection an owner. Do not let an apparently harmless record exercise contact a real customer or create a real order.
Use clear environment names and retain a short pre-flight record of the intended destinations. Those controls matter independently of sandbox type: a copied record is not a reason to trust every configured connection.
Keep the release and recovery decision separate
Before release, document the configuration being promoted, outstanding failures, deployment owner and recovery procedure. A passed sandbox test supports the stated workflow under the tested conditions. It does not prove every production record or integration will behave identically.
Use the Salesforce profile for the wider CRM discussion and the CRM migration guide to review relationships and handovers. This article describes environment selection and a proposed test brief; it does not report a Salesforce sandbox refresh or production deployment.
Frequently asked questions
Does a Salesforce Developer sandbox contain all production customer data?
Salesforce describes Developer sandboxes as copies of production configuration. Do not assume they include the complete production record set.
What is a Salesforce Partial Copy sandbox?
It includes production configuration and a data sample defined through a sandbox template, subject to the organisation’s entitlement and applicable limits.
Does using a sandbox automatically make every integration safe to run?
No. Review outbound destinations, jobs and connected services explicitly before exercising a workflow.