Demystifying Scratch Orgs for Salesforce

January 30, 2020 Roarke Lynch

With Salesforce DX, we’ve got two options for where we develop and test new features: sandboxes and scratch orgs. Although it might seem like scratch orgs are meant to replace sandboxes, that just isn’t the case. Both play critical roles in the healthy practice of DevOps in successful organizations. Let’s dispel some misconceptions about scratch orgs and set up a framework for understanding how they work alongside our trusted friend, the Sandbox. 

Sandboxes are copies of existing environments, either a production org or another Sandbox. Like our with production environments, we often create and maintain sandboxes with long lifetimes—months or even years. A cost in time and focus is required to maintain sandboxes and the limits that surround them make them precious. For some scenarios, that cost is worth it; for many others, it becomes a significant drag on valuable resources and attention. 

By comparison, scratch orgs are empty slates, intended to live only for a short period of time, seven days by default and never more than 30. Scratch orgs don’t start as a copy of another org; they start blank, and we then configure them by pushing in source code. The limitations of scratch orgs are a central feature in their value, but it can be a little hard to understand where they make sense if you’re not an ISV (independent software vendor). 

Unlike scratch orgs or even sandboxes, our production instances are permanent. We don’t get to ‘restart’ production and, even with very young orgs, we quickly expect them to handle many different interrelated functions. To manage the ever-growing complexity and sophistication of our production orgs, we need a way to think, plan, and build more abstractly. This is what we mean when we talk about modular architectures
 
Scratch orgs are how we build modules—custom applications, shared code libraries, and similar building blocks—that we can then publish as versioned packages. Sandboxes are how we manage the ongoing use and configuration of those building blocks for our production instances. It is not either/or, but rather BOTH that should play a role in the Salesforce strategy for your company.  

This is a very different way of thinking that won't come about overnight. However, this methodology is what will unlock the long-term potential of your teams and your investment in Salesforce. The promise of this transformation is what drives Appirio DX. Salesforce has given us the tools we need with Salesforce DX. Appirio DX builds on that foundation, closing the gaps between what Salesforce has made possible and what you need to make it real. 

Appirio DX tools and methodologies pick up where Salesforce DX leaves off to transform development on the Salesforce platform. It is a set of licensable tools and professional services from Appirio that helps you easily transition to a full DevOps methodology within the Salesforce ecosystem. Appirio DX tools reduce complexity and manage innovation without sacrificing trust. 

Want to learn more? Sign up for a demo. 

About the Author

Roarke Lynch

Roarke Lynch is Director of DevOps and Appirio Labs for Appirio’s Products and Innovation team. He is 8x Salesforce certified and has been developing and integrating on the Salesforce platform for over eight years. Roarke is from the Washington D.C. area and now lives with his wife in Houston, TX. In his spare time, you’ll find him chasing his one-year-old, fostering kittens, or geeking out over math, science, and economic innovations.

Follow on Linkedin More Content by Roarke Lynch
Previous Video
Understanding Package-Based Development on Salesforce
Understanding Package-Based Development on Salesforce

Next Video
How to Deliver More Accurate Project Estimates in Less Time
How to Deliver More Accurate Project Estimates in Less Time

Discover how Estimator, a project scoping and estimating tool, enables professional services teams to estim...