Developers often ask, “What’s the difference between a sandbox, a scratch org, and a Developer Edition org?” Or, “Why isn’t a Developer Edition org suitable for DX (also known as source-driven) development?” With so many different options, it’s no surprise that selecting the right type of org for the task at hand can be confusing. Some orgs types are optimized for taking advantage of our modern developer tooling, while others have a more narrow purpose.

In this blog post, we’ll answer those questions and help you determine which org type to use when navigating your Salesforce development journey.

Understanding Salesforce org types

First, let’s get familiar with the most common org types that Salesforce offers.

Production orgs 

A production org is the final destination for your code and applications, and it’s the primary environment where you conduct your day-to-day business operations using Salesforce. We recommend that you avoid modifying any code or metadata directly in production, which can introduce bugs or issues that can disrupt your business or your customers’ businesses. It’s important to practice good governance by enacting a change management process to minimize risks and ensure smooth operations.

To learn more about why you shouldn’t make changes directly in production, see the blog post Keep Your Org in Tip-Top Shape with Deployment Best Practices. 

Sandboxes 

A sandbox provides a safe space for developers and admins to experiment with new features and validate changes before deploying code to production. It’s a copy of your production org’s shape (licenses, features, and limits), metadata, and varying amounts of data depending on the sandbox type.

• Developer sandboxes are designed for individual developers or small teams. They provide a full copy of the production org’s metadata with only a small amount of data storage, and no data is copied when the sandbox is created or cloned. They’re designed for developing and testing new features, apps, and customizations. We recommend that each developer has their own sandbox to avoid overwriting each other’s changes, and especially if they’re using Salesforce developer tooling that takes advantage of source tracking.
• Developer Pro sandboxes are similar to Developer sandboxes, but they offer more storage space and data limits, making them a good fit for larger development projects or teams.
• Partial Copy sandboxes include a subset of production data along with full metadata. They’re intended for testing scenarios that require realistic data, such as user acceptance testing (UAT) and performance testing.
• Full sandboxes are exact replicas of the production org, including all data and metadata. They’re typically used for comprehensive testing, user training, and staging deployments before releasing changes to the production environment.

For information on storage limits, licenses, and refresh intervals, see Sandbox Licenses and Storage Limits by Type in the sandbox documentation.

So, why choose a sandbox as a development or testing environment?

• Developer and Developer Pro sandboxes with source tracking enabled can take advantage of many of the features of our Salesforce DX source-driven development tools, including Salesforce CLI, Salesforce Extension for VS Code, Code Builder, and DevOps Center.
• Partial Copy and Full sandboxes contain data! You don’t have to load test data manually.
• Sandboxes don’t expire if you log in to them on a regular basis.
• Sandboxes contain all the metadata from your production org. No additional configuration is required.
• When you start a new project, you can refresh your sandbox to ensure that it contains the latest metadata from your production org. Refresh intervals vary depending on the sandbox type.
• If you’re working on projects with longer timelines, using a sandbox ensures that your changes are persisted for longer than 30 days.

You can manage sandboxes in your production org or using Salesforce CLI. See Create a Sandbox in the sandbox documentation or Sandboxes in the Salesforce DX Developer Guide.

Scratch orgs

A scratch org is easy to create, fully configurable, and allows you to emulate different Salesforce editions with different features and settings. It’s a source-driven and temporary deployment of Salesforce metadata. Scratch orgs can be created for only a handful of Salesforce editions and have limited storage.  

Unlike sandboxes, scratch orgs start completely empty and aren’t replicas of your production org. Getting them to reflect the shape of your production org can require complex setup and data provisioning. Some newer scratch org features, such as Scratch Org Snapshots and Org Shape for Scratch Orgs, help you configure your scratch orgs faster. However, if you want the scratch org to be just like your production org, some manual configuration is required. Scratch orgs have a maximum 30-day lifespan, with the default set at seven days.

Like sandboxes, scratch orgs provide a development environment to develop and test new features, customizations, and applications before you release them to production.

When determining whether to use a scratch org or a sandbox, you might think that it’s a one-or-the-other decision. However, depending on the use case, team size, and application lifecycle stage, your team is more likely to use them in conjunction.

So, why would you choose a scratch org instead of a sandbox?

• They’re easy to spin up and discard.
• They’re compatible with our modern Salesforce DX tooling because source tracking is enabled by default.
• They’re independent of your production org, which means that you can enable and try out features and settings that don’t exist in your production org. While a sandbox is the same edition as its production org, you can choose the edition for the scratch org.
• During release transitions, you can also easily indicate the scratch org’s release version (preview or previous).
• Because scratch orgs are empty, they contain only the metadata that you deploy to them from a source control system. They don’t contain any cruft from abandoned projects, unused configurations, or experimentation. 
• You can create new scratch orgs within minutes vs. hours or days using Salesforce CLI, Salesforce Extensions for VS Code, or Code Builder. 
• You don’t have to worry about refresh intervals. As long as you haven’t exceeded your scratch org allocations, you can quickly spin up a new scratch org as needed.
• Because each developer uses their own scratch org, you won’t overwrite each other’s changes, which can happen in a shared sandbox.
• Scratch orgs were made for automated testing use cases, continuous integration and continuous delivery workflows (CI/CD), and performance testing. They also work well for peer reviews.
• Scratch orgs are vital to the second-generation package development process if you’re an ISV or partner.

See Scratch Orgs in the Salesforce DX Developer Guide for more information.

Developer Edition (DE) orgs

A DE org is a free org that provides access to many of the features and capabilities available in an Enterprise Edition org without the need for a paid subscription. They’re a great choice for learning and experimenting on the platform. DE orgs usually include features that don’t require a feature or permission set license.

However, DE orgs have some limitations, which make them less desirable for permanent development environments. The Salesforce Release Notes indicate which features are available in the most recent version of a Developer Edition org, which means that DE orgs can become out of date over time. Custom metadata and data in the production org aren’t synchronized with DE orgs, which means that DE orgs can become out of sync with production over time.

Unlike sandboxes, DE orgs can’t be refreshed, and they have limited data and storage. Unlike developer sandboxes and scratch orgs, DE orgs don’t have source tracking enabled, and they can’t be used as development environments for some Salesforce DX tooling, such as DevOps Center. Unlike production orgs, you can’t create sandboxes from DE orgs.

Some benefits of Developer Edition orgs include:

• They don’t expire if you log in to them on a regular basis
• You can enable Dev Hub, which allows you to create scratch orgs (three active, six daily)
• You can install and evaluate DevOps Center
• You can use them to create a namespace
• DE orgs are free, and you can sign up for as many as you like on the Developer Edition sign-up page
• You can connect DE orgs to Trailhead

Other orgs

Salesforce offers several other org types for special purposes and use cases.

Pre-release (preview) DE orgs: If you want early access to try new features for an upcoming release, you can sign up for a pre-release trial DE org, such as for Summer ’24.

Limited-time DE orgs: These orgs provide the ability to try out some of our new tools, such as Einstein Analytics for CRM or Einstein Copilot.

Trailhead Playgrounds: These free practice orgs are pre-configured with sample data and configurations. They’re integrated with Trailhead, allowing you to complete hands-on challenges associated with projects and modules within a safe environment. 

Trial Edition orgs: Temporary and limited-time versions of Salesforce orgs allow you to explore specific Salesforce apps or features. Salesforce partners use Partner trial orgs to showcase their apps and integrations. Salesforce offers several product and industry-specific free trial orgs. By trying before buying, you can make informed purchasing decisions.

Selecting the right org for each development stage

Now that you better understand the differences across org types, let’s discuss where they all fit in the app development process — what we commonly refer to as the Application Lifecycle Management (ALM) process.

ALM is the process of building and managing changes to your applications, from design to final release, to ensure that changes are introduced in a safe and governed way. There are three pillars to ALM: people, processes, and tools. In this post, we’ll focus on tools, specifically, which environments support which stages of the application lifecycle.

The ALM cycle has five stages, as illustrated below. 

If ALM is new to you, here’s a high-level overview of each stage.

Plan 

The planning stage is where you gather your team and define the requirements for your development project. This stage is also where you determine which tools you’ll use, how you’re going to break down and capture the work, and what types of development and testing environments you’ll need as your changes progress through the ALM cycle.

You might evaluate different tooling solutions and features in a DE org, see if an AppExchange solution is right for you in a trial org, or learn about new features in a Trailhead Playground.

Choose: Trial Edition orgs, Developer Edition orgs, Developer sandboxes, Developer Pro sandboxes, or scratch orgs.

Build 

The build stage is where requirements turn into working changes. Team members are assigned discrete units of work, each represented by a work item or ticket. Each developer performs their work in a dedicated development environment, but not directly in a production org. 

To take advantage of our modern DX tooling, you’ll want to select a source-tracked development environment.

Choose: Developer sandboxes, Developer Pro sandboxes, or scratch orgs.

Test 

The test stage contains multiple mini stages, such as unit testing, integration testing, user acceptance testing, testing at scale, staging, and training. The testing stages you include will be based on your company’s development and governance processes.

During the testing phases, you’ll likely want to test your integrated changes with some realistic customer data. Partial Copy sandboxes work well for user acceptance testing, while Full sandboxes enable you to test your changes with the full set of data from the production org. 

Scratch orgs are particularly suited for continuous integration/continuous deployment (CI/CD) workflows, and when developers want to quickly spin up development and testing environments to work in parallel on different features or projects. 

Choose: scratch orgs, Partial Copy sandboxes, or Full sandboxes.

Release

When you have fully tested your changes and your Apex code meets code coverage requirements, you’re ready to deploy those changes to your production org.

Choose: Partial Copy sandboxes, Full sandboxes, production orgs.

Observe

The Observe stage is where your Observability engineer can stay a step ahead by utilizing our suite of privacy and security tools, so they can monitor events and user behavior, or perform some A/B testing. During this phase, information is gathered that determines the next set of features, bug fixes, and product enhancements. By the time your team completes the Observe stage, you’re back to the beginning, where you take this information and use it to plan subsequent releases.

Choose: Full sandboxes, production orgs

Which org types support the latest developer features 

When Salesforce launches a new feature, it’s not always available in every development environment or production edition. Here’s an overview of the latest developer features and in which orgs they’re supported.

Summary

You now understand the purpose of each org type, in which situations they work best, and each org’s limitations. This blog post also introduced you to the ALM process and explained which orgs work best in each ALM stage. And you now have a quick cheat sheet on which orgs include our latest developer features. 

As you embark on your Salesforce development journey, we hope that you have more clarity around which type of development environment is right for you. 

Resources

• Well-Architected white paper: Resilient
• Developer Edition sign up
• Free trial edition orgs
• Trailhead Playgrounds
• Salesforce DX Developer Guide: Scratch Orgs and Sandboxes
• Documentation: Sandboxes

About the author

Emily Kapner is a Principal Technical Writer at Salesforce, where she focuses on creating technical content for Salesforce DX tooling. She loves interacting with the developer community and uses their feedback to drive what new content would be most impactful, to prioritize doc improvements, and to craft her content strategy.