In our first two blog posts of our Understanding Salesforce DX (SFDX) for Admins series, we explored how SFDX allows admins to easily sync their Salesforce configurations back and forth from org to desktop, and then use version control tools to maintain those resources.
You can access the first two blog posts here:
For our third and final introduction to Salesforce DX blog, we are going to learn how Salesforce helps you isolate your projects from the commotion of sandboxes thanks to the creation of scratch orgs.
Difference Between Salesforce Scratch Orgs and Sandboxes
As a Salesforce admin, you are all too familiar with production orgs, sandbox orgs, and the relationship between both environments. Scratch orgs take a very different approach to how a power user modifies their Salesforce environment. This process uses version control as the core of every project.
These are the key differences between scratch orgs and typical sandboxes you need to know about.
Scratch orgs are independent blank canvases
Up to this point, you have experienced sandboxes as clones of production environments. To create one, you have to request a refresh from production, and then Salesforce creates the sandbox by copying all metadata over to it. Your data will also be copied over from production for partial- or full-copy sandbox.
Scratch orgs are not tied to production orgs and are created independently. Additionally, scratch orgs have no metadata other than the standard out-of-the-box functionality you would get the first time you create a new org. There's no data associated with it.
As the name implies, you are truly starting from scratch when you create a scratch org. You can either use this blank canvas to begin a brand new project, or you can quickly initialize it with the contents of your version control to continue working on an old project. We will talk about the latter option again shortly.
The benefit of having an independent environment is that your scratch org is not influenced at all by what is currently living in your production or sandbox orgs. You are able to isolate and focus on a particular function without something unrelated affecting your work.
It’s your own Salesforce org
This scratch org belongs to you and only you. You do not have to share your environment with other admins or developers as you often do when working in sandboxes. While it is possible to allow another user to access your scratch org, the process is cumbersome and strongly discouraged.
This isolation eliminates the risk of having multiple people overriding each other when making changes to the same objects. That kind of conflict resolution is better suited to be solved inside version control systems. Version controls were built for that type of work.
Use sandboxes for quality assurance (QA) testing
Sandboxes only come into your Salesforce process for QA testing.
Once you have finished the work you are doing in the scratch org, you then deploy the contents of your project from your desktop to a sandbox that originated from production.
You can now test that your changes will continue to work within the context of everything else in your Salesforce org, which should now most likely be the case since you were able to keep your work separate from the very beginning.
Easily sync assets from scratch orgs
When working with change sets or metadata API integration functions in sandboxes, you need to specify which particular assets you want to include by either adding them to the change set or to a manifest file.
Specifying which assets to include is necessary because Salesforce does not want to sync everything between your two environments. There might be unrelated items you do not want to move yet.
But because you started from scratch and you focus on just a particular function for your scratch org, Salesforce DX assumes every change you make in your system is important, and it will sync everything back-and-forth with your local desktop. This way, you do not have to maintain a change set or manifest file to move your items around.
Use XML files with Salesforce DX
If you create a new custom field for Account on your scratch org, you will run a pull command on Salesforce DX for the tool to recognize the change on the scratch org and pull the XML file to your desktop. There is no need to remember which new field you created because it will be picked up automatically.
If you make a change to the label of the custom field directly in the XML file, you will save the XML file and then run a push command in Salesforce DX. The tool will then recognize the change you made on your desktop, and it will push the file back to the scratch org for you to view and test.
Salesforce DX team collaboration
The largest and most common sync your SFDX system will do is when you join a project already in progress. You will first pull the latest branch of files from the main branch of your repo to your desktop and then ask Salesforce DX to start up a brand new scratch org. Once the scratch org is ready, you run an initial push of all your project's components into the scratch org.
Now, you are no longer working with a brand new scratch org. You are working with a scratch org that is filled with the work of all your teammates before you. From there, you can start working on your contributions to the project.
Scratch Orgs are Temporary — Use Version Control!
Salesforce admins are well aware that sandboxes often go months — or even years — without ever being refreshed. This is because of the fear of losing work and changes that have not made it to production yet.
However, the longer the sandbox goes without being refreshed, the more out-of-sync it becomes with the rest of the system. This makes the sandbox far more unreliable for changes and development as time goes by.
The correct way of ensuring the changes you make to your org do not get deleted is to commit those changes to a version control system. The version control will contain a log of the work you did at any given time, and you always have the option of reverting the files back to that previous state if it ever gets deleted or modified. It doesn't matter what happens to your environment because you have all your work saved elsewhere.
Scratch org time limits
Salesforce DX enforces version control behavior by setting a very strict time limit for keeping a scratch org alive. You cannot fall back on Salesforce to save your work for you. If you do not actively commit your changes to version control, it will be deleted in a short amount of time.
The default length of time a scratch org is active is 7 days. You also have the option to keep the scratch org alive for a 30-day maximum. But there should never be a reason to extend the life of your scratch org as long as you follow the core rule:
Commit all of your work to a version control system as soon as you have finished making changes!
Then it won't matter if your scratch org expires tomorrow or three weeks from now. You can always create a new one, push your XML files to your new scratch org, and pick up where you last left off.
Taking the Next Steps with SFDX
We now understand the three core principles of Salesforce DX, which all Salesforce administrators should understand before jumping into the tools:
SFDX allows you to sync your Salesforce configuration and settings as XML and text files to your local desktop machine.
Those files can then be committed to version control systems, which can be shared among team members using cloud services such as GitHub.
You can keep your projects clean and organized by using independent scratch orgs to construct your setup, and then deploy your projects to sandboxes for testing.
At this point, you are ready to download the tools and begin your journey into SFDX. We recommend following step-by-step instructions in the App Development with Salesforce DX Trailhead module, which will let you know how to access SFDX and get started. This three-hour course will guide you through the setup process for configuring your SFDX tools as well as reinforce the core principles we discussed in these blog posts.
Working with command line tools and version control is a daunting task even among most developers. Please take your time with learning how to use Salesforce DX and reach out to the Salesforce community whenever you need help.
Salesforce DX Resources
Contact CRM Science Salesforce Consultants
Salesforce orgs at enterprise-level companies and nonprofit organizations often require complex configurations that go beyond instructional resources like Trailhead that are available to Salesforce administrators.
Salesforce DX is a great solution for Salesforce administrators looking to make declarative changes to Salesforce orgs. However, complex projects often require expert consultation and development from Salesforce-recognized partners.
Contact us to chat about Salesforce challenges and strategic technology projects that are puzzling you.
Comments