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.