What is Salesforce DX?
At Dreamforce 2016, Salesforce announced Salesforce DX-a new and improved way to develop on the Force.com platform. According to Salesforce, Salesforce DX would help developers “build together by deploying version control over everything across your code, org configuration, and metadata and leverage modern collaboration technologies such as Git and third-party test and build automation tools.” Since the announcement, developers everywhere have been itching to try their hands at the Salesforce DX. Fast forward to TrailheaDX 2017, a 2-day developer conference, Salesforce ushered beta of Salesforce DX in public.
While Salesforce developers everywhere are applauding Salesforce for a remarkable job of bringing the platform up to par with modern software development practices by launching Salesforce DX, admins are left wondering if they still fit into the development process. Salesforce has become one of the most accessible development platforms in the world by supporting both programmatic (code) and declarative (click) development. Unfortunately, the company has yet to lay out a clear way for admins to contribute to the development and release processes of a project using Salesforce DX.
So, is it still possible for admins to contribute, review, and deploy changes from a Salesforce DX environment? We believe that it is possible and this blog will show you how.
For ease of illustration, let’s consider the Dreamhouse App created by Salesforce (you can read about creating and configuring the App here in the ReadMe section). As an admin, imagine that you have been tasked to:
- Change the Field-Level Security information for the Phone field on the Broker object to ReadOnly on the StandardUser Profile.
- Create a Validation rule on the Property Object which checks the City field for blank values.
If you were able to follow the instructions and push the default data and configuration from Github into a scratch Org.; below are the steps you would need to follow as an admin using Salesforce DX:
Step 1 – Open the scratch org using the command - Sfdx force:org:open
Step 2 – Make changes you have been assigned in the Scratch org.
- Changing FLS setting on the Broker object for the StandardUser Profile.
- Create a Validation Rule on the Property Object
Step 3 – Pull these changes into your local checkout that you had created using the command -
As you can see, the Source Pull command only retrieves the changes Object (Property__c) but not the FLS setting that was changed on the Standard User profile.
To get the FLS setting, we will have to use Metadata API using a package manifest.
Step 4 – Create a package.xml file with the details of the Profile you would like to retrieve.
<?xml version="1.0" encoding="UTF-8"?>
Unlike, Metadata API retrieval request, you do not have to mention the dependent Object.Field permissions which you would like to retrieve. Salesforce DX retrieves the entire Profile information along with all CustomFields in the scratch org.
Save the above file as "package.xml" in a temp folder as your App – Dreamhouse in our case. See below for reference.
Step 5 – This is where we will retrieve the package.xml that we created in step-3; You will need to create a new folder (target directory) where the retrieved zip will be saved. See below for reference.
Invoke Metadata API using Salesforce DX using the following command -
sfdx force:mdapi:retrieve -r .\mdapi -k .\temp\package.xml
Go to the folder- 'mdapi' that has been just created and unzip the unpackaged components -
As mentioned earlier, the retrieved Profile will contain components from all CustomFields in the Scratch Org. You have an option here to delete all other components’ information OR you can keep the Profile file as is; depending upon the requirement. To keep my package lean, I chose to delete all other components.
Step 6 – We will now convert the retrieved Profile file from its MdApi structure to a Salesforce DX structure using the following command -
sfdx force:mdapi:convert -r .\mdapi\unpackaged
The folder path should be up till the package.xml file resides after the unzip in the previous step.
Project path indicates the folder in which the converted Metadata component resides.
Step 7 – As an admin, you now update the Salesforce DX source with the configuration changes you were tasked with; the updated source needs to be committed to your repository, and then it needs to be pushed to your remote repository. The tricky part here is to remove the temp folders that you have created while retrieving your components. See below for reference-
Use the following commands to Add, Commit and then Push your changes into your remote repository.
To add your files for Git versioning -
To commit your files (The commit message should ideally be your Userstory info from your ALM) -
Git commit –m "Property Validation Rule and Standard Profile FLS for Broker__c.Phone__c"
Git push origin master
For the admin, navigating the Salesforce DX CLI might be unwieldy, but it doesn't have to be so. A practical way to get the most out of Salesforce DX might be to include declarative changes as well as code changes in a version control system. A specialized GUI that empowers admins with a few button clicks might just be the way to ensure that the changes made by admins will be included in version control so that everyone on Salesforce development teams can experience the benefits of DX.