My name is Pablo, I’m the developer behind HappySoup.io, a very popular application for impact and dependency analysis. After working on this app for two years, I thought I knew all about Salesforce metadata. That changed when I joined Salto.

Salto allows us to manage the metadata and configuration of different business applications like Salesforce, Workato, and many others, in a centralized platform.

In this blog series titled Salesforce Metadata Reimagined, I’m going to walk you through my journey of discovering a new way of working with Salesforce metadata using Salto, and the benefits this can bring to the Salesforce developer community.

This particular piece is about how Salto’s technology works, and why it fits Salesforce so well. Check out other entries in the series to explore specific use cases:

‍‍Control your metadata with the Salto CLI + A unique approach to org comparison

‍

‍

Goodbye XML

Ever since Salesforce released the SOAP and Metadata APIs, Salesforce teams and partners have created countless applications that interact with Salesforce metadata via XML files.

Even through the evolution of Salesforce tools, from Workbench to the old Eclipse IDE and the newer SFDX Org Browser, the metadata has always been represented in XML (with the exception of the REST Tooling API).
‍

This has been the case for so long that we have accepted it as “a feature, not a bug,” and many Salesforce applications have complicated logic to parse, reorder, and compare XML files.
‍
Some challenges that come to mind when working with XML:

It’s difficult to compare

Did you know that the XML of Page Layouts is not always the same, even if nothing has changed in the page layout? The order of the XML nodes can change from one request to another.

Which means unless you have specialized software to reorder XML nodes, you might need to spend some time checking if the differences are real, or just out-of-order nodes. This also adds a lot of noise to your git repository because of the “false diffs.”

It’s inextensible

This is not exactly an XML problem, but the Salesforce XML files don’t allow you to add custom attributes to your metadata files.

What if you wanted to add an inline comment to the XML file of an important custom field? Every time you retrieve this metadata, Salesforce will override the XML and remove your comment. So even though your version control should be the source of truth (in XML), the actual source is always your org and how Salesforce decides that metadata should be represented.

‍

NaCl (Not another configuration language)

With Salto, you can interact with your Salesforce metadata in a format called NaCl. Let’s look at the same custom field from the image above:
‍

The same custom field is suddenly a lot easier to read. Notice how this resembles an object (in object-oriented programming) or a simple JSON data structure.
‍
When I first saw this, I thought: “Oh cool, is that it?” If you are thinking the same thing, I get it.

Being able to see your Salesforce metadata in an easy-to-understand format is not an amazing value proposition on its own. If you wanted, you could always create a script to parse the XML files and convert them into JSON files.

The real value is what you can do once your metadata is in this format. Let’s explore a few use cases:

Org Metadata Comparison

Using NaCl instead of XML removes all the issues that XML causes when dealing with calculating differences between metadata.
‍

Also, because of the way NaCl is parsed in Salto’s SaaS platform, you are able to do a very detailed comparison (attribute by attribute) of any metadata type, and be very selective as to which attributes you want to move over to a destination org.

Check out the org comparison part of the series for more details about why this is not just another org comparison tool.

Native Impact Analysis

In NaCl, every metadata item (a custom field, an apex class, etc.) gets an ID, which is then used in all the areas where that metadata item is referenced.

Let’s look at the XML of a Workflow Field Update:
‍

The field tag shows that the CustomerPriority__c field is the field being updated. But just by looking at this, we don’t know what object this field belongs to, and remember that custom field names are not unique across different objects.

If you were trying to find all the places where CustomerPriority__c is used through a simple text search in Visual Studio Code, you could find references to other custom fields with the same name but on different objects (I’ve seen this a lot in large orgs) or worse, you could be seeing references to a custom object that happens to have the same name as a custom field (yes, I’ve seen that too).

Now let’s look at the NaCl file for the same field update:
‍

This time, the field attribute points to a unique Salto ID:
‍
‍salesforce.Account.field.CustomerPriority_c
‍
This allows for native impact analysis because you can easily search for every metadata item that has a reference to this unique ID:
‍

The image above shows how easy it is to find all the places where this field is used. There’s no room for ambiguity here, those metadata items are definitely referencing that field, and could be impacted by any change you make on this field (hence the term impact analysis).

This unique metadata ID is also what powers our Find and Replace capability with a high degree of precision, something I plan to cover in a future article.

Treating data as metadata

One of my favorite benefits of this approach is that we can do all the things we’ve shown here (and much more) with data.

Why would you want to do that?

There are many Salesforce applications that use data for configuration, such as CPQ, nCino, etc. This is known as configuration data or reference data. These applications are so data-heavy, that it’s impossible to test them in dev sandboxes where the data is not present. At the same time, the data is so critical that a misconfiguration could break an entire quote-to-cash process.

With Salto, you can elevate the status of this data to become metadata, which means that we can:

• Version it in Git
• Deploy it across different orgs
• Compare it across different orgs
• Roll it back
• Perform impact analysis on it
  

This is a huge topic that deserves a whole article of its own, so for now, I’ll just show a preview of what CPQ data looks like in NaCl:
‍

Notice how this CPQ Price Condition looks just like the metadata files we saw earlier.

Salto Variables

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.

An easier and much less risky way of solving this problem is by using Salto variables.
‍

Salto allows us to create our own NaCl files with variable definitions. In this case, there’s a single variable to define whether validation rules should be active or not. We can then reference this variable in our validation rules NaCl files:
‍

Now our validation rule’s active property is not hardcoded to true or false, but is instead defined by the value of the variable. We can then change the variable’s value whenever we need, and all our automation will be disabled temporarily.

Notice how we didn’t have to create any Metadata API scripts, or even modify the rule criteria.
‍
This is an example of how NaCl is extensible where the Salesforce XML isn’t. This is when I had that “aha” moment and I’ve been hooked on NaCl ever since :)

Zooming out

As I said at the beginning of the article, Salto supports other business applications other than Salesforce, and everything that I covered here (and much more) applies to those applications as well.

To see the power of this, let’s have a quick look at what cross-app impact analysis looks like. Here we see that the Opportunity Stage field is being used in a page layout, as well as a Workato recipe that connects to NetSuite.
‍

Our cross-app capabilities are not limited to impact analysis, as you can also do cross-app deployments, rollbacks, comparison and much more.