• Scott VonShilling

Salesforce DX for Admins Part 1: SFDX Basics


Salesforce DX for Admins Part 1: SFDX Basics

When Salesforce introduced Salesforce DX a number of years ago, they opened the platform for developers to begin to use modern development tools within the Salesforce ecosystem. This great shift opened the doors for strategic Salesforce consulting partners like CRM Science to switch from sandboxes to scratch orgs for day-to-day deliveries.


But the launch of DX left many Salesforce administrators feeling like they were on the outside looking in. After all, the mantra for Salesforce admins has been “clicks, not code” for a while, so how can administrators understand coding tools and how to use them?


In this three-part series, we will explore what exactly Salesforce DX is from the point of view of an admin. And, we will kick it off with the single most important concept Salesforce admins need to understand: All Salesforce configuration is saved as text files!


Well, maybe not ALL Salesforce configuration. But, any item of Salesforce configuration you add to a change set is saved as a text file in the backend because the change set is just a collection of text files.


You can access the other two parts to this blog series here:


How to View Salesforce Source Code Text Files

You can view Salesforce source code text files by going into any deployed inbound change set.


Look for a "View Source" link next to each one of your deployed components. When you click that link, it will show you the text file comprising that configuration.

Change Set Components

If you view the source code for an Apex class or trigger, you will see the code a Salesforce developer has written. But, if you look at the source code from a declarative configuration, you will see that configuration expressed as an XML text file



Understand Salesforce XML Format Source Code Files

Understand Salesforce XML Format Source Code Files

The XML format looks very code-like, but if you take the time to read through it, you should be able to understand most of it.


XML format is a series of values nested between <tags> that label each value.


In the example above:


<label>Billing System Id</label>


The phrase "Billing System Id" sits between the tags that say "label." So, the file is telling you the label of the custom field is "AirTable ID."


<length>255</length> & <type>Text</type>


This custom field is of "text" type and the length is 255 characters, which is a very common scenario you would create declaratively as a Salesforce administrator.


<externalId>true</externalId> & <unique>true</unique>


Now we are seeing "external id = true" and "unique = true", which means this custom field is a unique external id field.


Declarative View of Salesforce XML File

This is how that XML file is normally presented to a Salesforce administrator with arrows on the five lines discussed in the example above.



Declarative View of Salesforce XML File


Basically, any part of the configuration screen a Salesforce administrator is able to set is going to be saved in this type of XML file format. And, when you update the configuration item declaratively, Salesforce will automatically update its corresponding XML files with the changes you made.


Now you understand that every Salesforce configuration item you work with is saved as a text file, which means we can talk about what Salesforce DX actually does.



How Does Salesforce DX Work?


Salesforce DX (also known as SFDX) allows Salesforce administrators and developers to easily sync source code or XML text files between Salesforce orgs and local computers.


Salesforce DX allows Salesforce developers to sync text files containing code they wrote.


Salesforce DX allows Salesforce administrators to sync XML files used for declarative work.


When you deploy your declarative changes via change set, you have a very hands-off approach to how the process works. You upload and deploy your change set between two orgs, and you let Salesforce transfer your XML files from cloud to cloud, as illustrated below.

How Does Salesforce DX Work?

Salesforce DX changes this process by allowing those XML files to be synced and stored in your local computer, as shown here:


How Does Salesforce DX Work?

Why Use Salesforce DX?


Why would you want to save your files locally in XML format?


Quickly Edit Salesforce Orgs


Storing Salesforce source code via XML files saved locally to Salesforce administrators’ computers allows them to update Salesforce orgs easily because they can make changes in an XML text file and deploy using Salesforce DX.


Need to quickly change the label of a custom field? Make it required?


You don't have to navigate to the custom field in a potentially slow Salesforce sandbox. Simply open that XML file on your desktop, modify the two lines representing those settings, and let SFDX sync the changes to the sandbox.


Clone XML Files for Virtually Identical Validation Rules


Need to make six virtually identical validation rules with just one simple number change in the evolution criteria? You are not going to find a clone button in the Salesforce user interface (UI).


Instead, here is a faster way to deploy six almost identical Salesforce validation rules in one shot:

  1. Create one validation rule in your org

  2. Pull it to your desktop as an XML file

  3. Clone the XML file five times with different names

  4. Make your small change to each file

  5. Push the changes back to your org via XML file with SFDX.


Now one validation rule quickly turned into six.


That’s one example of how easy it is to make Salesforce org changes using XML files with Salesforce DX, and admins can complete many Salesforce project tasks by simply editing XML files and pushing to Salesforce orgs with SFDX.


However, the biggest reason Salesforce admins should save XML files locally is… version control!


Use Salesforce XML Files for Version Control


When you have control of the text file on your desktop, you then have the ability to enter it into a version control system.


This is a topic that requires a deeper explanation, so I will discuss using Salesforce XML files for version control in more detail in Part 2 [Coming Soon!] of this series.


Practice Using XML files

But in the meantime, click the “view source” links on the various components you deploy in your change set. Get yourself familiar with the different types of settings you can read and understand in that XML file.


If you made a change to any value in that XML file, how do you think it would affect what you would see in your admin screen?


Salesforce DX Resources


Contact CRM Science Salesforce Consultants

Salesforce orgs at enterprise level companies and nonprofit organizations often require complex changes that go beyond resources like Trailhead that are available to Salesforce administrators. Salesforce DX is a great solution for Salesforce awesome admins looking to make declarative changes to Salesforce orgs. However, complex configuration changes often require expert consultation and development from Salesforce-recognized partners.


Contact CRM Science, a Salesforce Gold Consulting Partner, to discuss your most puzzling Salesforce challenges and strategic projects.

Contact CRM Science Salesforce Consultants


Recent Posts