Different Salesforce Sandbox types

Different Salesforce Sandbox types help teams build, test, train, and validate changes away from the live production org. Salesforce commonly provides four sandbox types: Developer Sandbox, Developer Pro Sandbox, Partial Copy Sandbox, and Full Sandbox. The main differences are the amount of production data copied, refresh interval, storage limit, and whether a sandbox template can be used.

1. Full Sandbox.
2. Partial Data Sandbox.
3. Developer Sandbox and
4. Developer Pro Sandbox.

Salesforce Sandbox is a separate copy of your Salesforce production environment. It is used for development, testing, quality assurance, user training, integration testing, and release validation without changing live production data or configuration. When a sandbox is created or refreshed, Salesforce copies metadata from production, and the data copied depends on the sandbox type.

For the current Salesforce reference, see Salesforce Help for Sandbox Types and Templates, Sandbox Licenses and Storage Limits by Type, and Refresh Your Sandbox.

Different Salesforce Sandbox types compared by data copy and refresh interval

The right Salesforce sandbox type depends on the work you are doing. A small configuration change may need only a Developer sandbox. A release that must be tested with realistic records may need a Partial Copy sandbox. A performance test or final pre-production rehearsal may need a Full sandbox.

Sandbox Type	Refresh Interval	Storage Limit	What Copies from Production	Sandbox Template	Best Used For
Developer Sandbox	1 day	Data Storage: 200 MB File Storage: 200 MB	Metadata only	Not Available	Configuration work, Apex development, Flow changes, and isolated unit testing with manually created test data.
Developer Pro Sandbox	1 day	Data Storage: 1 GB File Storage: 1 GB	Metadata only	Not Available	Development and testing that needs more records or files than a Developer sandbox can hold.
Partial Copy Sandbox	5 days	Data Storage: 5 GB File Storage: Same as production org	Metadata and sample production data defined by a sandbox template	Required	QA, integration testing, UAT, and training with a controlled sample of realistic data.
Full Sandbox	29 days	Same storage limit as production org	Metadata and all production data	Available	Final release validation, performance testing, regression testing, data migration testing, and realistic user training.

Note  Each Salesforce sandbox type has a different limit for data storage, file storage, and refresh frequency. Object records count against data storage; files, documents, and Chatter files count against file storage. Always verify limits in your own Salesforce org because sandbox availability depends on edition and purchased licenses.

Full Sandbox Salesforce for production-like testing

A Full Salesforce Sandbox includes all metadata and all data from your production org. This means configuration, code, automation, users, object records, custom setting records, files, and related data are copied into a separate test environment. For example, Accounts, Contacts, Opportunities, Cases, Leads, and custom object records from production can be available in the Full sandbox.

A Full sandbox is normally used when the test result depends on production-like data volume, record relationships, sharing rules, or integrations. It is useful for regression testing, load and performance testing, user acceptance testing before a major release, data migration rehearsal, and end-user training.

• Field history: You have the option of copying a configurable amount of field history data from production.
• Chatter data: You can include Chatter posts and activity from production if the sandbox needs those records for testing or training.

Before creating or refreshing a Full sandbox, check whether production data should be masked, whether outbound integrations should be disabled, and whether email deliverability settings are safe for a non-production environment. Full sandboxes contain sensitive business data, so access should be limited to users who need it.

• Use a Full sandbox when record volume, real relationships, or production-like sharing behavior must be tested.
• Avoid using a Full sandbox for everyday development when a smaller Developer or Developer Pro sandbox is enough.
• Plan refreshes carefully because the Full sandbox refresh interval is longer than other sandbox types.

Partial Copy Sandbox Salesforce for QA with selected production data

A Partial Copy Salesforce sandbox includes production metadata and a selected sample of production data. The selected objects and records are controlled by a sandbox template. This makes Partial Copy useful when testers need realistic data, but the team does not need the entire production database.

Partial Copy sandboxes are commonly used for functional testing, integration testing, UAT, and training. For example, a service team may copy a sample of Accounts, Contacts, Cases, and related custom records to test a new case escalation process. A sales team may copy selected Accounts, Contacts, Opportunities, and Products to test a quote or approval process.

• A sandbox template is required for a Partial Copy sandbox.
• Only selected objects and sample records are copied, so test data may not include every relationship found in production.
• Partial Copy is usually faster and smaller than Full, but it still provides more realistic test data than Developer or Developer Pro.

Developer Sandbox and Developer Pro Sandbox for configuration and code work

Developer and Developer Pro sandboxes include metadata from production, but they do not automatically include production data. They are suitable for configuration changes, Apex development, Lightning Web Components, Flow updates, validation rules, page layouts, and permission changes where a small set of test records is enough.

If extra records are needed, you can create them manually in the sandbox or load test data using Data Loader. For example, if you need a sample of Accounts, Contacts, Opportunities, Cases, and Leads, you can prepare small CSV files and import only the records required for the test case.

The main difference between Developer and Developer Pro sandboxes is storage. A Developer sandbox has a smaller storage limit, while a Developer Pro sandbox provides more space for test records and files. Both can be refreshed more frequently than Partial Copy and Full sandboxes, which makes them useful for active development work.

How to choose the right Salesforce sandbox type for a release

Use the smallest Salesforce sandbox type that can support the test objective. This keeps refreshes simpler, reduces data exposure, and avoids consuming a larger sandbox license when it is not needed.

Project Need	Recommended Salesforce Sandbox Type	Reason
Build or test a validation rule, Flow, page layout, or Apex class	Developer Sandbox	Metadata is usually enough, and small test data can be created manually.
Develop a feature that needs more sample records or files	Developer Pro Sandbox	It provides more storage than Developer while keeping a daily refresh interval.
Run UAT with realistic Accounts, Contacts, Opportunities, or Cases	Partial Copy Sandbox	It copies metadata and selected sample data by using a sandbox template.
Validate a major release before production deployment	Full Sandbox	It gives the closest match to production data, configuration, relationships, and storage scale.
Practice a data migration or integration cutover	Full Sandbox or Partial Copy Sandbox	Use Full when complete data volume matters; use Partial Copy when selected representative data is enough.

Sandbox templates in Salesforce for Partial Copy and Full sandboxes

A sandbox template lets you choose which objects are copied into a Partial Copy or Full sandbox. Templates are important when you do not want every object or every related record copied. For Partial Copy, the template is required because it defines the subset of data to include. For Full sandboxes, a template is available when you want to limit the data copied instead of copying all production data.

When planning a sandbox template, include parent objects and important child objects together. For example, if you select Opportunities but do not include related Accounts, Contacts, Products, or custom lookup records that your automation expects, tests may fail because the sample data is incomplete.

Salesforce sandbox refresh behavior and data safety checks

Refreshing a sandbox replaces the existing sandbox copy with a newer copy from production. Any changes made only in the sandbox can be lost if they are not deployed, backed up, or recreated. Before refreshing, confirm that development work has been moved to the correct target, test records are no longer needed, and users know that the sandbox will be replaced.

• Developer and Developer Pro sandboxes can be refreshed after 1 day.
• Partial Copy sandboxes can be refreshed after 5 days.
• Full sandboxes can be refreshed after 29 days.
• Production email addresses, integration endpoints, scheduled jobs, and automation should be reviewed after refresh.
• Use masked or reduced data when testers do not need real customer or business-sensitive information.

Editorial QA checklist for Salesforce sandbox types

• Confirm the article states all four Salesforce sandbox types: Developer, Developer Pro, Partial Copy, and Full.
• Check that Developer and Developer Pro are described as metadata-only copies unless test data is manually created or imported.
• Check that Partial Copy is described as metadata plus sample data controlled by a sandbox template.
• Check that Full is described as metadata plus all production data, with template availability where applicable.
• Verify refresh intervals in the comparison table: 1 day, 1 day, 5 days, and 29 days.
• Verify storage limits against current Salesforce Help before publishing updates, especially if Salesforce changes license or storage upgrade rules.
• Confirm the tutorial reminds readers to review integrations, email deliverability, scheduled jobs, and sensitive data after sandbox creation or refresh.

FAQs on different Salesforce Sandbox types

Summary: Different Salesforce Sandbox types serve different release needs. Use Developer or Developer Pro for development and small tests, Partial Copy for selected production data, and Full for production-like validation. Choosing the correct sandbox type helps teams test safely while keeping production data and configuration protected.