Understanding Salesforce Scratch Orgs

Revision of Salesforce Orgs

Let's quickly cover the different kinds of orgs we usually deal with when working with the Salesforce platform. If you have ever studied for a Salesforce certification exam, you would've come across a module explaining what each of these orgs is used for. This quick summary will help refresh that.?

Production Org

A production org is the final destination for your code and applications, and it’s the primary environment where you conduct your day-to-day business operations using Salesforce. It is recommended that you avoid modifying any code or metadata directly in production, which can introduce bugs or issues that can disrupt your business or your customers’ businesses.

Sandbox

A sandbox is an org that provides a safe space for developers and admins to experiment with new features and validate changes before deploying code to production. We have different types of sandboxes:

1. Developer sandboxes are designed for individual developers or small teams. They provide a full copy of the production org’s metadata with only a small amount of data storage. They’re designed for developing and testing new features, apps, and customizations. It is recommended that each developer has their developer sandbox to avoid overwriting each other’s changes.?
2. Developer Pro sandboxes are like Developer sandboxes, but they offer more storage space and data limits, making them a good fit for larger development projects or teams.?
3. Partial Copy sandboxes include a subset of production data along with full metadata. They’re intended for testing scenarios that require realistic data, such as user acceptance testing (UAT) and performance testing.?
4. Full sandboxes are exact replicas of the production org, including all data and metadata. They’re typically used for comprehensive testing, user training, and staging deployments before releasing changes to the production environment.

What are Salesforce Scratch Orgs?

Now, you might have already worked in the above kinds of orgs but none of these are what we call scratch orgs.?So, what exactly are scratch orgs then? Let's move on to that!

Salesforce scratch orgs are temporary environments specifically designed for development and testing purposes. By default, they do not contain sample data, workflows, profiles, permission sets, apex classes, triggers, or pages. In short, scratch orgs are completely empty and they don’t contain much of the sample metadata that you get when you sign up for an org, such as a Developer Edition org.

They are also fully configurable which means that developers can add different features and settings as they like. In addition to code and metadata, developers can also install packages and deploy synthetic or dummy data for testing.

So scratch orgs are for development and testing and we just talked about how different sandboxes are also created for development and testing purposes. Where exactly does the difference come in? Let’s look at that.

Scratch Org v/s Sandboxes

1. Accessibility: Scratch orgs are designed primarily for developers using Salesforce Developer Experience (Salesforce DX) and Salesforce command-line (Salesforce CLI) tools. In contrast, Sandbox is available to not only developers but also testers, administrators, and business users within the Salesforce ecosystem.
2. Configuration: As we just said, scratch orgs are fully configurable using configuration files. On the other hand, sandboxes can only be configured to a small extent but even that is not usually required since it already has all the metadata from Production.?
3. Creation speed: ?Scratch orgs can be created in minutes. Sandboxes are slower compared to scratch orgs, and the creation time varies depending on the sandbox type.
4. Initial State: Scratch orgs are completely empty initially. On the other hand, even new sandboxes at least have all of the Production metadata and the data is there depending on the sandbox type and edition.
5. Storage space: Scratch orgs are limited in terms of storage, data, and feature availability compared to production orgs or full sandboxes. Scratch org has 200MB for data and 50 MB for files whereas the Partial copy sandbox has 5GB of each which is a huge difference.
6. Life span: Scratch orgs are short-lived. By default, they are set to expire in 7 days but you can increase that to 30 days at a maximum. Sandboxes do not expire if you log into them regularly.
7. Cost: Scratch orgs are included in Salesforce DX licenses whereas sandboxes usually require additional cost depending on type and edition.
8. Refreshable: Scratch orgs cannot be refreshed; they must be recreated for changes but you can refresh a sandbox from a production org or another sandbox to mirror current data and configuration.

Hopefully, that explained the difference between a scratch org and a sandbox and gave you more understanding of scratch orgs. In summary, we say that they are isolated and disposable salesforce orgs used for development and testing which you can spin up in an instant and also get rid of them in minutes once you’re done with them.

Configuration Files

As we mentioned, scratch orgs are fully configurable. There is a file named project-scratch-def.json which makes all this configuration possible. It has the following elements:

• Org name & Edition: You set up some basic things for your org like your org name and the edition for your org. Common editions are Developer, Enterprise, and Group. In the screenshot below, we have set the org name to "My Scratch Org" and the edition is set to Developer.

• Enabled Features: Lists the Salesforce features and functionalities that should be enabled in the scratch org. For example, "Communities" enables Communities, "ContactsToMultipleAccounts" allows contacts to be associated with multiple accounts, and so on.

• Org Settings: Configures various org-wide settings that impact the behaviour and capabilities of the scratch org. An example of settings is the Org Preference Settings where you can define whether users can set their passwords via the API or whether you want to enable networks.

Another example is the Security Settings where you can set password policies such as when it expires, and maximum login attempts.

Data Files

Additionally, if you want to import some dummy data into the scratch org, you can create JSON data files that look like the following screenshot:

In type, you write down which object will have the following record. After that, you write the field names on the left side and the value for that field on the right.

There are also ways you can export data from your production org or other sandboxes and use it here but of course, there is a data storage limit when it comes to scratch orgs. Also, it is not recommended to seed personal or sensitive data into scratch orgs.

Setting Up Scratch Orgs

Pre-requisites

1. Salesforce DX setup on your laptop?
2. Salesforce CLI is successfully installed?
3. A DevHub org is enabled

The Dev Hub is a Salesforce org that you enable as the central point for creating and managing scratch orgs. It can be your production org, a Developer Edition org, or a trial Hub org. The Dev Hub org edition determines how many scratch orgs you can create daily, and how many can be active at a given point.

Commands in Salesforce DX and CLI tools

Step 1: Log into your DevHub environment:

sf org login web -d -a DevHub        

Step 2: Create a scratch org by providing the path to your configuration files.

sf org create scratch -d -f config/project-scratch-def.json -a dreamhouse-org        

-d: set this scratch org as the default org

-a: give this org an alias name such as dreamhouse-org

Step 3: Open your new scratch org.

sf org open        

And that's it! You can now see your new scratch org which took less than a minute to create.

Additionally, you can deploy data and metadata into this new, empty org with the following commands:

//Deploy source metadata to Scratch Org
sf project deploy start

//Assign a Permission Set 
sf org assign permset -n Dreamhouse

//Import data into the scratch org (give it the path to the data files)
sf data import tree -p data/sample-data-plan.json        

You can delete a scratch org by using the following command or going into your DevHub environment and searching up Active Scratch Orgs in the App Launcher to manage it there.

sf org delete scratch -u dreamhouse-org -p        

Practical Use Cases for Scratch Orgs

1. Agile Development: Can quickly spin up scratch orgs to develop and test new features independently.?
2. Automated Testing: Integrating with continuous integration (CI) pipelines allows for automated testing of changes.
3. Feature Development: Used to prototype and iterate on new Salesforce features in a controlled environment.?
4. Training and Demos: Useful for onboarding new developers, providing environments for training, and showcasing functionality to stakeholders without affecting live systems.