Zero to Hero With Salesforce Scratch Orgs

Salesforce Scratch Orgs have been part of the platform since they announced Salesforce DX at Dreamforce in 2016. 

But, we have yet to see the level of excitement that we do for other releases, such as the CLI. As a matter of fact, there’s no standalone Trailhead Module for them (although it is included in other modules).

As part of my interviews with prospective Salesforce Developers, I ask them about their experience with Scratch Orgs. The level of involvement varies, but I typically see ISVs use them more than embedded developers.

If we were to run a poll amongst most Admins and ask them if they use Scratch Orgs as part of their development process, we’d receive a resounding no.

Why is this the case? We’ll explore this question throughout this article and also walk through how to get started with Scratch Orgs as part of your development (to include declarative) process.

What Are Scratch Orgs

Scratch Orgs are source control-driven temporary environments that can exist between 1-30 days.

What does this mean? For simplicity, we can consider Scratch Orgs as streamlined throwaway sandboxes.

They were built with the idea that they could be used within a DevOps process. Set up and torn down when needed for a specific purpose.

This helps us keep our environments fresh and avoid any dependency issues.

They can be set up and torn down automatically as part of your pipeline. You can set them up as each feature branch, keeping your content fresh. 

Unlike traditional sandboxes, you can create and tear them down multiple times daily. Although, it is essential to know that there are still limits on how many Scratch Orgs are allocated.

Differences Between Scratch Orgs and Sandboxes

Both Scratch Orgs and Sandboxes are considered temporary environments. 

They are used for developing and testing features before being released to production.

One of the best features of Scratch Orgs is the fact that we can push and pull code changes directly from the CLI through commands like `force:source:retrieve`

However, recently Salesforce introduced a Beta feature called Source Tracking. This allows us to use the same commands with Sandboxes as Scratch or Developer Orgs.

We can choose what we want to include in a Scratch Org. This dramatically improves the speed at which we can start a new org. This behavior is ideal when we want to spin up a new test environment after a major release for testing.

The most significant difference between the two is the ability to create/refresh your scratch org multiple times a day. You are limited to refreshing a Developer sandbox once a day. 

True, you could make numerous Developer sandboxes to work around this. Still, you will eventually reach your limits for the number of used sandboxes.

Why Use Scratch Orgs

Scratch Orgs are used heavily in the ISV space, where packages are the primary development method. We see development akin to traditional software teams.

But, as Salesforce DevOps continues along its maturity path, we will see Scratch Orgs grow in popularity.

Within traditional software development, we utilize the engineer’s local device (or perhaps a virtual machine somewhere else) to develop and test before pushing to a different environment.

For Salesforce, these local devices are Sandboxes managed within Salesforce’s platform. One developer/admin affects another’s work if we run out of Sandboxes. This causes coordination issues and the potential for merge conflicts.

Since we have more latitude in the number of Scratch Orgs, we can create, this allows us more room to work independently. Engineers and Admins working on a feature branch together can cluster naturally.

Using Scratch Orgs as our development environment and our Sandboxes as our pipeline, we unlock some magic. Scratch Orgs for local work and our Sandboxes for integration, User Acceptance Testing, and staging.

Why Are Scratch Orgs Not Being Used?

We’ve explored the many benefits of Scratch orgs which may lead to a natural question: if they are so helpful, why are they not prolific?

Difficult to Stay in Sync With Production

The most prominent reason is that until recently, they were an enigma. There were multiple ways to create and design them, leading to frustration and exhaustion.

As changes occurred in production, we would have to ensure these changes were pushed to the Scratch Org. This is relatively easy if you’re using a source-controlled development process but nearly impossible otherwise.

Luckily, Org Shapes were introduced in the Winter ’21 release. This allows us to create a template that mimics production and keep our orgs in sync.

No Major Reason For Smaller Organizations

Smaller companies often do not run against their sandbox allocations. With few admins or engineers, there is no real need to share sandboxes, and the pain isn’t felt as much. 

The work is also more easily visualized. While a small team may work on multiple projects at once – we should talk about the perils of WIP another time – they understand what is in their org end to end.

These smaller organizations also tend to focus on non-package-based deployments. Releasing through change sets as features are released. Advanced teams may adopt source control, but this is usually seen as a need for enterprise teams. 

Over the past few years, a lot of time and energy has been focused on Salesforce DevOps. Salesforce itself just released its own DevOps Center to manage pipelines.

This has drawn attention to how we develop locally and push work through environments – even in smaller organizations. Yes, even as a Solo Admin, we can utilize DevOps.

As such, we should begin to change our development paradigm. Smaller organizations can begin to use the same development patterns as larger organizations. This leveling up starts to become a focus.

They Can Be Confusing

One of the significant advantages of Salesforce, and why it draws any career switchers, is its ability to manage the platform primarily through clicks, not code.

As Scratch Orgs were designed with engineers in mind, those who embrace the CLI and can visualize those same clicks as metadata, this breaks from the standard design pattern.

The CLI can be intimidating. It lives locally, not in the cloud. It is text and keyboard-driven, not UI driven. We have to remember a lot of commands to navigate.

Who wants to use Scratch Orgs and get past that learning curve if we’re presented with a significant learning curve with the CLI?

I totally get it.

I’m excited to see more declarative tools introduce ways to manage Scratch Orgs. This allows teams to work the way they work best.

Two of my favorite implementations of this are AutoRabit and Gearset. Both platforms have implemented Scratch Org management that is friendly to all team members.

UI-minded team members can use these tools, while CLI-minded team members can use the CLI. These teams can use both if they so choose! What’s better than that?

Set Up a Scratch Org

There are a couple different ways of setting up a Scratch Org, from using an Org Shape to a manifest. We will cover Org Shapes in a later article, so for the purposes here, we will use a simple manifest. 

More about manifests can be found in this article from Salesforce.

Enable Dev Hub

If you’re not aware yet, a good majority of posts on this site will start with enabling Dev Hub. There are a few dependencies to be resolved, which are outside of the scope of this post, but suffice it to say it’s a good thing to have turned on.

Create a Definition File

Definition files allow us to get creative with how we want our org to look. For this walkthrough, we will utilize the sample file from Salesforce.

{
  "orgName": "Acme",
  "edition": "Enterprise",
  "features": ["Communities", "ServiceCloud", "Chatbot"],
  "settings": {
      "communitiesSettings": {
          "enableNetworksEnabled": true
      },
      "mobileSettings": {
          "enableS1EncryptedStoragePref2": true
      },
      "omniChannelSettings": {
          "enableOmniChannel": true
      },
      "caseSettings": {
          "systemUserEmail": "support@acme.com"
      }
  }
}

The definition file sets the settings we want within our scratch org.

You may name the file whatever makes sense for you and your team; for our purposes, we will name it project-scratch-def.json

Create the Scratch Org

The next few steps involve using the terminal, which can be intimidating. I recommend Codecademy’s lessons on using the command line if you’re not familiar with it.

Fire up a terminal/CLI session and run the following command:

sfdx force:org:create -f project-scratch-def.json -a MyScratchOrg --setdefaultusername

The following is displayed:

Successfully created scratch org: 00D3D0000000PE5UAM, 
    username: test-b4agup43oxmu@example.com

The values for scratch org (a Salesforce ID) and username will vary for each scratch org that you create.

So what did we just do here?

sfdx force:org:create this is the base command to create a Sandbox or Scratch Org via the CLI

-f project-scratch-def-.json this parameter indicates that a definition file should be used; we specify the name of the definition file we created earlier.

-a MyScratchOrg here we create an alias for our Org, specifically MyScratchOrg, that we can use to indicate what orgs we want to open

--setdefaultusername is a handy parameter that we use to indicate this is the default org we want to use with our project. It keeps us from having to specify an org name each time.

Congratulations, you have created your first scratch org. Don’t believe me? Type the following command:

sfdx force:org:open -u <username/alias>

where <username/alias> is the username displayed in your Sandbox Org creation confirmation above.

If all goes well, your new scratch org will open in a new browser window and authenticate automatically.

My Favorite Tips

These all require the CLI, but there are a few handy lines:

Conclusion

While I don’t see Scratch Orgs gaining massive popularity overnight, I believe that we will continue to see their use increase.

The value of being able to spin up a scratch org with the details that you want, open it, begin development, and sync to your source control cannot be measured.

If we combine this with automated test suites and data seeding, we can harness great productivity gains.

It is my belief that Admins and Developers who understand Scratch Orgs will have an advantage over those who are unfamiliar with the concepts as we continue to mature in DevOps within the Salesforce ecosystem.

This is why I continue to post about the power of Salesforce DevOps and how we can continue gaining knowledge. 

What’s been your favorite use of Scratch Orgs that you’ve seen?