Scratch Orgs vs. Sandboxes: Salesforce Environment Management Strategies

Innovative Salesforce application development requires different environments to work through the different stages of development. Along with maintaining your Production org, you should have development, testing, and training done in different environments. Software delivery is mostly a process of promoting changes through these different environments, so it’s important for us to have an overview of Salesforce environments and how to manage them.

Firstly, for anyone new to the platform, there’s an important clarification (veterans, feel free to skip this paragraph). Please note: your Salesforce org is not a server – it’s not something that you can run locally, you can’t put it on your corporate network, and you can’t provision it onto a cloud infrastructure provider like AWS or Google Cloud. All Salesforce development, testing, and usage take place within a Salesforce org, and Salesforce orgs can only ever be provisioned by Salesforce in one of their own data centers, accessible only via the public internet. This was a strategic decision by Salesforce that ensured that they could control the infrastructure, the upgrade process, and access to the underlying intellectual property. There are never outdated versions of Salesforce running behind a corporate firewall despite how badly we want it to manage our own infrastructure.

Another reason why orgs exist in this way is somewhat of a contradiction. There are actually no orgs. What I mean by this is that not only is an org not a server, it’s not a virtual machine, it’s not a cluster, it’s not a container. So, what is an org exactly? An org is actually just a unique ID that allows Salesforce to isolate the data and metadata that belong to one customer from the data and metadata of all other customers.

To better understand this concept, think of Salesforce as a single massive application, running on a single massive database, with all customer data in that same database, partitioned by a single 18-digit Org ID starting with 00D. The many layers of carefully constructed security, application, and database optimization are then used to generate a unique experience in each Salesforce org so that it appears to function as a completely independent instance.

So, when we talk about environment management, the process is somewhat different from the process on other platforms. It is still important to distinguish different types of orgs and how to provision different orgs for different purposes. For practical purposes, there are only 3 types of orgs that most people need to know about: Production, Sandboxes, and Scratch Orgs. These different types of orgs behave in almost identical ways but have different limits and features.

Salesforce production orgs are the ones you pay for. They come with different features depending on which edition and licenses you buy. Each edition is progressively more expensive but offers increasing capabilities and higher limits on data storage, sandboxes, API limits, and so on. Sandboxes are for long-lived work – development, testing, or training. Primarily copied from production, you can now create sandboxes off of sandboxes, with varying levels of data storage. Scratch orgs, a key part of the Salesforce DX workflow, are similar to sandboxes but intended for ephemeral needs. It’s a production org that has been enabled to create scratch orgs, which we call a “Dev Hub.” While it can be used for dev, test, and training, it contains no data or metadata from the prod org. Their short lifespan (30-day limit) should be seen as a feature, not a limitation. This forces teams to not rely on an org being their source of truth, but instead to capture all relevant configurations in version control.

Despite the title of this blog, it is important to note that it’s not an either-or debate. Scratch orgs aren’t here to replace Sandboxes, they are here to complement them. There are disadvantages to using sandboxes as development environments, but they are still useful as long-lived testing and training environments. Whatever you do, just don’t develop directly in Production.

To learn more about environment management and Dev Hub, contact us!