Demystifying Scratch Orgs for Salesforce

Roarke Lynch
3 min readAug 27, 2020

--

Photo by Joshua Sortino on Unsplash

Learn how to unlock the long-term potential of your Dev teams and your investment in Salesforce.

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 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.

--

--

Roarke Lynch

Among other things, I am a science, tech, and economics geek.