Test Organization
A Test Organization in Salesforce is a non-production Salesforce org used for development, QA, UAT, training, or any other activity where changes need to be validated before reaching the live production org.
Definition
A Test Organization in Salesforce is a non-production Salesforce org used for development, QA, UAT, training, or any other activity where changes need to be validated before reaching the live production org. The term covers several specific types: Developer Sandboxes, Developer Pro Sandboxes, Partial Copy Sandboxes, Full Sandboxes, and Scratch Orgs. Each type has different storage limits, data refresh behavior, and intended use case.
The platform treats every Test Organization as a separate Salesforce org with its own org id, data, and metadata, isolated from production. Metadata and (depending on the type) data flow from production into the Test Organization through sandbox creation or refresh. Changes made in the Test Organization flow back to production through change sets, Salesforce DX deploy, ANT migration, or another deployment tool, never automatically.
Test Organizations on the Salesforce platform: types, refresh, and strategy
The five types of Test Organization and how to pick one
Salesforce ships five types of Test Organization and each one fits a different need. Developer Sandbox is the smallest (200 MB data, 200 MB files), refreshable daily, and meant for individual developer work. Developer Pro Sandbox is larger (1 GB data, 1 GB files), refreshable daily, meant for a small team working on the same feature. Partial Copy Sandbox includes a sample of production data based on a Sandbox Template (5 GB data, 5 GB files), refreshable every 5 days, meant for QA and integration testing with realistic but not full data. Full Sandbox is a full copy of production (matches production data and file storage), refreshable every 29 days, meant for UAT, performance testing, and pre-release staging. Scratch Org is a short-lived, source-driven org built from a project definition file, meant for feature branch development and CI.
Sandbox refresh: what changes and what stays
Sandbox refresh is the operation that copies the current production org metadata (and depending on the sandbox type, data) into the existing sandbox. The org id stays the same, so external integrations pointing at the sandbox URL do not need to be re-configured. Sandbox refresh deletes everything that was in the sandbox before. If your team has done work in the sandbox that has not been deployed back to production, that work is lost on refresh. Always confirm uncommitted work has been deployed or backed up before triggering a refresh. Refresh cooldown periods vary by sandbox type (1 day for Developer, 5 days for Partial Copy, 29 days for Full), so plan refresh cadence around the project timeline.
Scratch Orgs and source-driven development
Scratch Orgs are different from sandboxes in three important ways. First, they are created from a Dev Hub org rather than refreshed from production, so they start empty and are populated by deploying source from a Salesforce DX project. Second, they expire automatically after a defined number of days (7 by default, up to 30 maximum). Third, they are intended to be disposable; a developer creates one for a feature branch, works on it, deploys back to source control, and deletes it. Scratch Orgs are the foundation of modern source-driven development on the Salesforce platform and are the recommended environment for any new project that uses Salesforce DX, Git, and CI.
Sandbox Templates and data subsetting
Sandbox Templates are configurations that control which objects get included in a Partial Copy Sandbox or a Full Sandbox refresh. The template specifies which standard and custom objects to copy and what record limit applies. The default template copies a 10,000-record sample per object for Partial Copy and the full data set for Full. Custom templates let you reduce the data footprint (excluding objects you do not need for testing) or focus the data set on a specific business unit. Templates are useful for performance: a slimmer sandbox refreshes faster and uses less storage. They are also useful for compliance: excluding sensitive objects from a sandbox used by external consultants reduces the blast radius of any access mistakes.
Login URL, user identity, and Test Organization isolation
Every Test Organization has its own login URL with a test prefix (test.salesforce.com for production sandbox login, login.salesforce.com for production proper). Usernames in sandboxes are auto-suffixed with the sandbox name on refresh to ensure they are unique across orgs. For example, alice@example.com in production becomes alice@example.com.devsbx in the dev sandbox. This means sandbox users have to log in with the suffixed username, which often surprises new users. Each Test Organization has its own License Management, its own integration users, and its own external system connections. Changes to one do not affect any other. This isolation is the entire point of having Test Organizations, and any feature that breaks isolation (such as outbound integrations that point at production endpoints) is a configuration bug.
Choosing a Test Organization strategy for your team
Most established Salesforce teams use a layered Test Organization strategy. Individual developers work in personal Developer Sandboxes or Scratch Orgs. Feature work integrates in a shared Developer Pro or Partial Copy Sandbox where multiple changes can be tested together. UAT and pre-production validation happen in a Full Sandbox refreshed shortly before each release. Production deploys happen from the Full Sandbox after sign-off. Adopting source control and Salesforce DX shifts the bottom of this stack toward Scratch Orgs and away from individual Developer Sandboxes; the upper tiers (Partial Copy, Full) remain mostly the same. Document the strategy explicitly in the team release process so new joiners do not invent ad-hoc patterns that diverge from what works.
Creating, using, and refreshing a Test Organization
Creating a Test Organization is one of the most common admin and developer tasks on the Salesforce platform. The exact steps differ between sandboxes and scratch orgs, but the high-level workflow is the same: pick the right type for the job, create it from the right source, populate it with the metadata and (if relevant) data you need, give the right users access, and deploy your changes back to production when validation is complete. This guide covers the standard sandbox path; scratch orgs follow a separate Salesforce DX flow.
- Pick the right sandbox type for the work
Choose based on the data and refresh cadence you need. Developer Sandbox for individual feature work where you do not need much data. Developer Pro for small team work or when 1 GB of data is enough. Partial Copy for QA against a representative slice of production data. Full Sandbox for UAT, performance testing, integration testing, or anything that needs the actual production data shape. Picking too small forces a redo later; picking too large costs storage license and refreshes slowly. Confirm with the release engineering team if your org has a published sandbox policy that may constrain choices.
- Create the sandbox from Setup
Open Setup, Sandboxes, click New Sandbox, and pick the type from step 1. Give the sandbox a short clear name (avoid spaces and special characters; the name becomes part of the user suffix). Select a Sandbox Template if you want to control which objects get copied. Click Create. Sandbox creation takes minutes for Developer types, hours for Partial Copy, and up to a day or more for Full Sandboxes. Salesforce sends an email when the sandbox is ready. You cannot use the sandbox until that email arrives.
- Give users access and validate the org
Once the sandbox is ready, log in at test.salesforce.com using your suffixed username. Confirm your profile and permission sets came over from production. Run smoke tests on critical record types and integrations. Activate any sandbox-specific outbound integration endpoints (the sandbox should never call production external systems). Grant access to the developers and QA users who need it by activating their suffixed user records and resetting their passwords. Document the access list and the sandbox purpose in the team release tracker so the org is not orphaned when its initial owner moves on.
- Deploy changes back to production
Work in the sandbox, then deploy the validated changes back to production through your chosen deployment tool. Change Sets are the lightweight option for small admin-level changes. Salesforce DX deploy is the modern path for source-driven projects. ANT migration is the legacy option still used in some shops. Whichever tool you use, capture the deploy result, the diff that was applied, and the test execution log in your release tracker. Refresh the sandbox after the deploy so future work starts from the new production baseline rather than the pre-deploy state.
- Sandbox refresh deletes every change made in the sandbox since the previous refresh. Confirm all uncommitted work has been deployed back to production or backed up to source control before triggering a refresh.
- Sandbox usernames are suffixed with the sandbox name on refresh. Users have to log in with the suffixed username, and external integrations using the unsuffixed name will fail until reconfigured.
- Sandboxes inherit outbound integration endpoints from production by default. Without reconfiguration, the sandbox may call real production external systems and produce real-world side effects (orders placed, emails sent, payments triggered).
- Scratch orgs expire automatically (7 days default, 30 days max). Work that has not been pushed to source control by the expiration date is lost. Build the push to source as a daily habit, not an end-of-feature one.
- Refresh cooldowns are not the same across sandbox types. Developer refreshes daily; Full Sandbox only every 29 days. Plan the release schedule around the cooldown, not the other way around.
Trust & references
Straight from the source - Salesforce's reference material on Test Organization.
- Sandbox OverviewSalesforce Help
- Scratch Orgs (Salesforce DX Developer Guide)Salesforce Developer Docs
- Create a SandboxSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Test Organization?
Q2. What types exist?
Q3. Why use test orgs?
Discussion
Loading discussion…