This is the second entry of the Salesforce Metadata Reimagined series, in which I walk you through my personal journey of discovering a new way of working with Salesforce metadata using Salto.

This time, I’m going to walk you step by step through some interesting use cases where Salto allows us to deal with Salesforce metadata in a new (and better) way. For this, we’ll use the Salto CLI.

The use cases I’m going to explore today are:

• Turning off all your validation rules with Salto variables (perfect before a data migration)
• Mass creating custom fields
  

I know…there are already proven ways to do this and it’s nothing groundbreaking. However, with Salto’s NaCl, we can take this to a whole new level and reason about it in a more expressive way. This foundation will become important for you to explore more advanced use cases later on.

‍

‍

The Salto CLI

Salto comes with three different offerings, two of which you can start using today for free:

• The Salto CLI (free and open-source)
• The Salto Free Tier (free forever, not a 30-day trial)
  
• The Salto SaaS paid solution
  

The CLI is a great option for those of us who like being on the command line. It allows for deploying changes to the org and for managing the configuration.

The free tier is good for small teams that need an easy way to explore their org’s metadata, as it comes with powerful features for text search (across your metadata), impact analysis, and automatic notifications when that metadata changes (something I really like and haven’t seen as a free offering in any other product).

The paid version combines the features of the CLI (deployment) and the free tier, plus a set of features for better management of your org’s metadata, like comparison, find and replace, git version control, etc.

‍

Installation and setup

Before we start, go to our GitHub repository and follow the instructions to download and install the CLI and the Salto vscode extension. If you have any issues with this, please reach out to us!
‍
Assuming you have installed the Salto CLI, let’s get started.

‍Create a new Salto workspace

‍In your terminal, run the following commands:
‍
mkdir salto_cli
cd salto_cli
salto init
‍

The CLI will prompt you for the name of your first environment, let’s call this developer_sandbox. The other commands will create a new directory named salto_cli which will serve as the workspace for this project.
‍
Connect to your Salesforce org

‍Now run the following command:‍

‍salto service add salesforce

‍This command will prompt you to enter the credentials for your account, please do so.
‍

Fetch your Salesforce metadata

‍A Salto fetch operation is what you’d normally know as a Metadata API retrieve, and that’s actually what’s happening behind the scenes (plus a few more things).

Let’s retrieve your org’s metadata:
‍
salto fetch
‍

This might take a minute or two, after which your workspace will contain a bunch of .nacl files which correspond to your Salesforce metadata.
‍

At this point, you might be wondering what’s the big deal so far. Isn’t this the same as creating an SFDX project and retrieving your metadata via the package.xml file?

While the process is similar, there are a few advantages:

The metadata for all standard objects was retrieved. This is not something you can do with SFDX unless you specify the name of every standard field in your org. This is because the CustomObject metadata type does not support the wildcard operator.

You can easily include reports and dashboards by removing Report, ReportFolder, Dashboard, and DashboardFolder from the exclude list in salto.config/adapters/salesforce/salesforce.nacl.

Again, something that you cannot do with SFDX because you’d have to specify the folder of every report and dashboard.

Turning off all validation rules

This use case is mentioned in the first part of our Salesforce Metadata Reimagined series. In this article, I’ll show you how to actually go about it.

It’s a very well-known practice to turn off validation rules, workflows, triggers, etc., before importing records (whether inserting “dirty” data in this way is a good or bad thing, is a whole other discussion).

Traditionally, Salesforce teams have approached this problem in two ways:

• Actually deactivate all the automation, either manually or via a Metadata API script. Insert the records, and turn everything back on.
• Modify all their automation to reference a custom setting or custom metadata type with a boolean field, and the automation would be configured to not run if the boolean field is false.
  

The first option is error-prone and time-consuming, while the second one is probably the best way to go and the most efficient.
‍

A challenge with this approach is that you have to modify every single validation rule, workflow rule, trigger, process builder, flow, etc., to include the custom metadata type field in the triggering condition. This is not a small task.
‍
Teams can usually pull this off when creating new validation rules but previously created rules are typically left behind because of the risk of editing their criteria.

So let’s see another way of doing this with Salto variables. Our example is with account validation rules, but this applies to any other object (in other words, feel free to use any other object in which you have validation rules, or create a new validation rule in the Account object if you don't have any).

Let’s head over to Salesforce/Objects/Account/ValidationRule.

In our case, we have two validation rules, both of which are active:
‍

Now, right-click the ValidationRule folder and create a new file called flags.nacl and populate it with the following block:

Now, let’s mass edit the active attribute of all of our account validation rules. You can do this by using a scoped Find and Replace operation in vscode, as follows:
‍

Then click Replace All.

This will replace all the active attributes of your account validation rules to point to the new Salto variable.
‍

And now, simply execute the following command:

‍salto deploy -p
‍

A nice touch here is that Salto will show you what’s changed in your workspace—notice that you didn’t have to specify what you wanted to deploy or what changes you’ve made. This is similar to SFDX Source Tracking but with a few advantages:

• It supports all metadata types
• It supports configuration data (like CPQ)
  
• It works for Production orgs
  

Type in y and let’s wait for the deployment to finish:
‍

Now, if you check your validation rules in Salesforce, they’ll be deactivated!

Let’s try the reverse now. Just edit the variable to be true and once again run the salto deploy command. You’ll now see that your validation rules are active again. Nice!

Mass creating custom fields

Let’s see now how easy it is to mass create custom fields. Let’s head to salesforce/Objects/Case/CaseCustomFields.nacl
‍

This file contains all your Case custom fields.
‍

Scroll down to the bottom of the file, and add these two blocks just before the last closing bracket:
‍

That’s it, now lets run the following command:
‍
salto deploy
‍
When the command finishes, the two new custom fields will be updated with their API name and label and if you go to your Salesforce org, you’ll see the two fields right there!
‍

This was incredibly easy and would be very useful when mass creating fields for an integration job or the like, where you don’t care too much if the field label is the same as the API name, as these fields will typically not be included in page layouts.

And that’s how easy it is to use the Salto CLI. You might still have some questions like:

• How does this interact with SFDX?
• Does this support CI/CD?
  
• What about changes made directly in Salesforce?
  

I plan to cover these and many more topics in a future article. Stay tuned…