Traditionally, Salesforce development was always done in sandboxes. When something was done, you moved it using a change set, or some other metadata deployment tool. But a few years ago Salesforce introduced a new development model: scratch orgs and package-based development. And it’s left lots of people wondering: Where should I be doing my development? In a sandbox or a scratch org?
‍
In this article, I’ll provide a simple rule of thumb on when to use each.

‍

‍

What is a scratch org?

A scratch org is a whole new type of org that anyone can create directly from the Salesforce Command Line Interface (CLI). It is, however, empty without any data or metadata. It’s similar to creating a new trailhead playground or a developer edition org. 

Why would you want an org without any data? Because you can develop new features and know that nothing else will interfere with your code. There’s nothing else but your code, so there are far fewer variables. If something’s not working, it is most definitely your code, and not someone else’s customization. (Sorry.)

Scratch orgs also only exist for a short period of time. They’re automatically destroyed every seven days, unless you extend it, which ensures a consistently clean work environment.

Where is scratch org metadata stored?

It isn’t. Because scratch orgs expire in seven days, you lose that metadata, unless you keep everything in a version control system like Git. Salesforce encourages this, and the Salesforce CLI provides a push command to easily export your metadata to a local repository, and deploy it back to a scratch org.

‍

This is a very important point: To use scratch orgs successfully, you need to store all your metadata in a deployable state within that git version control system. This is common for Salesforce independent software vendor (ISV) developers who work on a specific package of metadata that can easily be deployed to any org. But for companies using Salesforce themselves, as end users, scratch orgs present significant challenges.

Scratch org vs sandboxes

I’ve explained sandboxes thoroughly in this post, so I won’t go into too much detail. The big difference between the two is that sandboxes do not automatically expire, they contain varying levels of real data, and they always have a “source org” that they’re created from, of which they are a copy. 

‍

At a more philosophical level, scratch orgs are meant to be used for Package Development, whereas sandboxes work better with Org Development. And to know which is right for you, it’ll help to understand the difference. 

Org Development versus Package Development

Prior to the launch of Salesforce DX, most Salesforce teams followed a typical waterfall approach to releasing new features: They would make the changes in a sandbox org and, once ready, deploy those changes to production (while also pushing the changes to some intermediate sandboxes for testing, UAT, etc.). This is known as the Org Development Model. 

With Salesforce DX, Salesforce introduced a new, more modular way of deploying changes, known as the Package Development Model. In this model, you break down your metadata into logical packages (one package for service cloud, another for finance, etc.) and develop and test those packages in totally blank scratch orgs.

In this model, scratch orgs work well because, in theory, your package doesn’t have too many external dependencies, so its source code stays in a deployable state (not always the case with sandboxes), which means you can easily deploy it to a scratch org (compared to trying to deploy an entire production org into a scratch org).

But does that mean you can’t use scratch orgs with the Org Development Model? Actually, there’s a way.

How to use scratch orgs with org-based development

If you want to use scratch orgs as a company using Salesforce (org-based), you can achieve it in one of two ways:

1. Deploy the entire production metadata into a scratch org each time

You could create a SFDX project and include all your metadata in it. From here, you can push the entire org metadata into a scratch org. Salesforce has always discouraged this approach, for several reasons:

1. It’s difficult to store all your metadata in a deployable state. Some metadata has dependencies and relies on managed packages or paid features from Salesforce which don’t exist in the scratch org. If deployed, they won’t work.
2. It slows the scratch org creation down considerably, because it takes longer to load.
3. You are essentially just creating a sandbox, in which case, just use a sandbox. It already has your production org metadata. 
   

2. Deploy a select portion of the metadata into the scratch org

This one’s much simpler. Pick a set of metadata that can be independently deployed, which isn’t dependent on the entire metadata. A good way to begin is to identify a component that can act as your entry point—say, an Apex class. Figure out what that component depends upon to exist. This is known as a “deployment boundary.” 

Once you identify the deployment boundary, you can use that metadata (along with the top-level component) as your source, and push that into a scratch org. From that point onward, you can do any changes in the top-level component just as if you were doing development in the original source org.

If you’re using Salto for this, you can easily see the dependencies of each metadata component. This will be captured as “generated dependencies” under the top-level component. What you see below represents all the metadata that is used by the top-level component, and thus is needed if you wanted to work on the top-level component in a scratch org.

The next logical question would be: If it takes so much work to use scratch orgs with org development, why bother?

Some Salesforce orgs could benefit from following the Package Development model for some parts of their org. For example, perhaps all your finance information is stored in six distinct custom objects, where these custom objects have their own triggers, flows, etc. It may be possible to extract these objects and all their dependencies and create a package out of them. Then, moving forward, you can use the Package Development model only for that set of configuration.

This could help the team who owns the package have their own release cadence and process, completely disconnected from the one for the org-level customization. This allows them to have more independence and to track their changes with more confidence, as each release would update the package version. 

‍

So which is it? Scratch org or sandbox? 

Now that you know the relative differences, and know how to achieve org-based development within a scratch org, here’s some general guidance. 

Remember the business need

Having read all this, perhaps you’re feeling that by not using scratch orgs, you’re missing out. What I would caution is to remember to put the business’ needs first. Are you better off using Package Development and scratch orgs? Or can you clearly justify why this will result in better ROI? If you can, then by all means go for scratch orgs. Otherwise, sandboxes are a trusty backup with some of your data and fairly easy to use.