Knowing how to automate the Salesforce CLI can greatly streamline your development workflow, cut down on tedious tasks, and serve as the foundation for continuous integration and delivery (CI/CD) processes. In this guide, we’ll explore how Salesforce developers can leverage scripting to automate common Salesforce CLI commands. This technique will make it easier to manage complex deployments, set up environments, and perform routine tasks, all while saving time and increasing the reliability of your Salesforce projects.

Scripting the CLI with Bash

You may have heard that the Salesforce CLI is scriptable—but what does that actually mean? A script is a combination of multiple commands that, when put together, form an end to end process. With scripts, you can automate an infinite number of development tasks, which is essentially the foundation of CI/CD. Instead of deploying with the Salesforce CLI by writing commands manually, we can create scripts to automatically run some Salesforce CLI commands. Let’s take a look at how that scripting works.

For our examples, we’ll be using a new org using one of the Trailhead Sample apps (in our case, the E-Bikes one). If you’re not familiar with Trailhead Sample Apps, they’re basically sample applications that the Salesforce team put together so you can explore many different features from Salesforce. For example, the one we’ll be using (E-Bikes) explores how to create a community using Lightning Web Components. These apps are nice because they have many design patterns for both deployment, CI/CD, and also Apex and JavaScript patterns. And, because you typically have to run a lot of different instructions in your scratch org to get them to work, they’re a good example for automating.

‍

‍

When we go to one of the repositories, we’ll see it’s full of instructions on how to get one of these apps up and running. We’ll also see a ton of different commands, such as authenticating the dev hub, creating a scratch org, pushing the code to the scratch org, assigning a permission set, importing some data, publishing the community, etc. This is a great opportunity for automation because, if our team is working on an application like this that requires multiple SFDX commands to get it running, it’s a hassle to have to run those commands one by one. There’s also the problem of having to remember them or copy and paste each command from a document.

Let’s automate all of these commands so that we can set up this scratch org with all the metadata of this GitHub repo with a single command. Note that we will need to complete the first two steps of the instructions manually because they require some user interaction.

‍

‍

First, we’ll log into our dev hub, which is what will allow us to create scratch orgs. We’ll copy the command from the instructions and run it in the terminal. The second step is to clone the GitHub repo and navigate to that folder, so we’ll do that by copying and running the command shown in the instructions. Then, in Visual Studio Code, we’ll see that we have the SFDX project with all the metadata for this sample application.

‍

The next step given in the instructions is to create a scratch org. Once the scratch org is created, we’ll need to push the source—meaning the entire project—into that scratch org. Then, we’ll need to assign two permission sets to the user and import some sample data using a given SFDX command. After that, the next steps are to publish the community site, deploy more metadata, and finally open up the scratch org.

One way we can do this is to create a new file and then put all those commands inside that file. We can see that we have a scripts folder that comes by default, so let’s create a new file there called setup-org.

‍

‍

We’ll now copy all of the commands found in the instructions and drop them into the file we just created, as shown in the image below.

‍

‍

Now we can use the source command (which is a Unix command rather than an SFDX command) to execute whatever is written in that file. The source command allows us to execute a file and that file in turn will contain other commands. This is the basis of scripting something with bash. We’re scripting something through the shell. 

Let’s try that with our SFDX scripts, automating everything end to end with just one line. We’ll run this command:

‍

‍

And now we’ve created the scratch org! We’re pushing the source to that scratch org, and all of this is happening without us having to do anything else. We could go get a cup of coffee, come back, and the deployment will likely be complete when we sit back down.

Once everything is deployed, this will also automatically assign the two permission sets, import the data, and execute another deployment of guest profile metadata, after which our scratch org will be up and running. Through scripting, we’re able to automate all these commands—which is incredible. 

This is essentially what a script is, the ability to take multiple commands, not necessarily from SFDX, and put them together as a bundle that we can execute in one go. This bears repeating because, as the foundation of CI/CD, it’s important to understand the fact that the Salesforce CLI can be run automatically with scripts.

There are, of course, infinite use cases for this. Although our example uses scripts to set up an org, you could also have scripts for deploying certain metadata to different sandboxes or to remove sensitive information from the org. The sky’s the limit.

Scripting the CLI with npm

There are other ways to create scripts within a Salesforce DX project, which is actually an npm project. If you haven’t heard of npm, it’s the node package manager, which is the way Node.js packages are created. Every Node.js package has a package.json file, and in the file you can also write some other scripts. These scripts are basically the same in that they’re either SFDX commands, other bash scripts, or anything else that you can write in the terminal. The difference is that you can put them in the package.json file and call them through npm.

Let’s say we want our developers to have a simple script to deploy all the Apex classes to the org. At the end of the scripts found in the package.json file, we’ll add a new one (in this example we’ll name it deployApex), followed by the SFDX command.

‍

‍

We’ll run the script using the following command:

‍

‍

This will start executing the real command, which is the source deploy command. Later on, if we configure the CI server for CI/CD, this is basically what we’ll be doing. We’ll tell the CI server to run different Salesforce CLI commands at different times, which is only possible because the CLI is scriptable. You can put it on scripts that you can call through package managers or directly through the terminal.

Fun Fact:

The E-Bikes project from above contains a bin folder, inside which are two files—one for Windows and one for Unix systems—that do exactly what we just did. Basically, these files contain a shell script that automates the same commands that we automated earlier. It does look a bit different as it uses variables across the code and prints to the terminal what is happening, but it’s a nice example of another way to achieve the same results.

In a Mac or a Linux machine, you would run this via the following command:

‍

Conclusion

Now that you’ve seen how to use scripting to automate Salesforce CLI commands, take a moment to think about this question: What could you automate in your own org?  Could you deploy certain metadata or have a simple command to deploy Apex class? Or maybe a simple command to import sample data to a new sandbox that just got refreshed? Think about what you could do, find what SFDX or Salesforce CLI commands can help you with that, and decide if you can script them. You most likely can.