A best practice for building and configuring new solutions is to always build and test outside of your production org. But what org type should you use for building and testing? There are many resources that break down sandboxes and scratch orgs separately—but on the Admin Relations team, we often hear from admins who want clarification about the difference between the two and when to use them. In this post, we’ll provide a quick overview of both sandboxes and scratch orgs that can help inform as you decide what development and testing approach is best for your organization.
Sandboxes are copies of your Salesforce org that you can use for development, testing, and training, without compromising the data and applications in your production org. There are different sandbox types and templates you may use based on your use case. We’re not going to break down all sandbox types in this post, so check out this Help Article to learn about all the details. Sandboxes don’t expire, so as long as you continue using the sandbox, it will stay active.
One type of sandbox Salesforce Admins commonly use for deployment, testing, and training is a developer sandbox. Developer sandboxes are a copy of your Salesforce production org’s metadata; they bring over all the metadata, all the customizations, but not the data itself. They’re often used for building and testing in an isolated environment.
Scratch orgs, on the other hand, are meant to be ephemeral environments used specifically for source-driven development. Let’s break down what this means!
Ephemeral environments aren’t intended to be long-lasting—they’re short-lived copies of your org or information that are intended to be used for a specific purpose. Scratch orgs expire—they have a default expiration of 7 days and a max lifespan of 30 days—so they’re an ephemeral environment. Because of this short expiration timeframe, scratch orgs are disposable and not intended to be the long-term home of any customizations.
Scratch orgs are used specifically for source-driven development. Source-driven development is a modern way of building changes and one that Salesforce has adopted over the last 5 or 6 years. With source-driven development, you’re populating a development environment (that is, your scratch org), with an externalized source, rather than copying it from the production org. Once changes have been made in a scratch org, they need to be synced back to a source control system (like GitHub).
Today, scratch orgs can be created through the Command Line Interface (CLI). While this may seem complicated, there are a lot of resources out there to help, and new declarative options are on the way. Scratch org Product Manager Rohit Mehta encourages admins to take a closer look at scratch orgs, as they can improve the speed that you’re able to deliver complex projects.
Here’s a useful analogy that Senior Director of Admin Evangelism, Mike Gerholdt shared with me that helped me wrap my head around the topic. For this analogy, think of a production org like a chair. Whenever you change or modify a chair, those changes become the source of truth for the chair. So if you wanted to create another chair exactly like it, you’d have to go to the chair, pull it apart, and recreate the part.
But with an externalized version control system (like you use with scratch orgs), you have an instruction manual for making a chair. You can make changes to the manual, hand that manual to 100 people, and they can reproduce the chair. That’s because the instruction manual—version control system—is the source of truth. Whereas with the previous version, you’d have to give the chair to 100 people if they wanted to replicate it because the chair is the source of truth.
Salesforce is continuing to invest in sandboxes and in scratch orgs; and based on your company and use case, it may make sense to use one or the other—or even a combination of both as you build and test solutions.
If you’re using sandboxes for building and testing today, continuing with this approach may be best for you! Sandboxes are easier to create and can be used for development, testing, and training. Because they don’t expire, they can be used over long periods of time.
To utilize scratch orgs effectively, you need to be using a source-driven development approach. If this isn’t something you and your company are familiar with, scratch orgs can pose challenges, particularly with their 30-day expiration timeframe. After scratch orgs expire, the data cannot be recovered. It can be extremely disheartening to build solutions in a scratch org and then be unable to recover solutions once the 30-day timeframe has passed. There can be benefits to this approach: They’re fully configurable and can be used to emulate different Salesforce editions with different features and preferences, but it’s critical to understand some of the limitations as well.
Learn more about sandboxes and scratch orgs with the following resources:
You asked; we listened. We’re proud to announce the new Who Sees What Lightning Experience series, updated with the latest best practices on data visibility and access. Follow along with this video series to ensure you’re adhering to the best practice of least privilege access: giving your users the data access they need—and only what […]
Selling has become a team sport, with 81% of reps saying team selling helps them close deals. For Salesforce Admins, enabling a team selling approach can create both opportunity and some complexity. Team selling weaves in many of the core responsibilities admins practice each and every day, such as permission sets, security, and data management. […]
Join us and discover the new Spring ’23 release features for admins and developers. We know each release brings with it lots of amazing new functionality and there can be a lot to digest. With Learn MOAR, we’re packaging the release and bringing it to you in an easy-to-digest format with blogs, videos, and more. […]
