This is the third entry of our Salesforce metadata reimagined series, where I walk you through my personal journey of discovering a new way of working with Salesforce metadata using Salto.

In our first two installments, I spoke about why NaCl is better than XML for working with Salesforce metadata, and how to use the Salto CLI to perform various metadata operations.

This time, I want to go back to NaCl and show how it enables very detailed metadata comparison between two orgs.
‍

This is useful when migrating metadata from one org to another, or when analysing differences between orgs to understand what is causing a deployment to fail.

Now, org comparison is not a new concept, and there are both free and paid apps that provide this capability. What I like about Salto’s way is how granular that comparison is, and the ability to be very selective as to what changes you want to reconcile.

It’s worth mentioning that while this core capability is available in the open-source CLI (under the salto env diff command), I’m showing here what it looks like in Salto’s SaaS solution which has extended user experience and functionality in this area.

‍

‍

Metadata Comparison

With Salto, we can compare any metadata type against two orgs, like fields, LWCs, profiles, case settings, etc. I’m going to focus on comparing profiles, but all the features I will show here apply to any other metadata type. The first step is deciding which environments I want to compare.
‍

Once the comparison is ready, I can start browsing through the orgs’ metadata and see the differences.
‍

When it comes to profiles, the first thing I like is how I can browse through the different sections that make up a profile, like apex class access, field permissions, etc.
‍

When it comes to profiles, the first thing I like is how I can browse through the different sections that make up a profile, like apex class access, field permissions, etc.
‍

This allows me to be very quick and specific about what differences I care about.

And it doesn’t stop there, once I drill down to one of these sections, I can also browse through the different objects. For example, this allows me to only see the differences between the Field-Level Security (FLS) of this profile for the Account object.
‍

At this point, I would think this is enough granularity, but it turns out, you can then see the individual attributes of a field’s FLS, and choose which ones you want to reconcile.
‍

In the above screenshot, the dots represent my different Salesforce orgs.
‍

What I’m seeing here is the editable and readable properties of the field are different in the other org, and with the checkboxes next to them, I can select which one I want to move (what we call clone) to the other org. In this case, I only want to clone the readable property of this field’s FLS.
‍

Finally, I can deploy this change to the target org with just a few clicks.
‍

This level of granularity is a huge advantage over change sets. With change sets, when you include a profile, the system permissions are also included and deployed to the target environment, even if you only intended to deploy a couple of FLS. This can cause major issues if for some reason, the profile in the source environment has different system permissions than its counterpart in the target environment.

So this capability can be used for two different reasons: to deploy specific profile sections to a target environment, or to reconcile differences between profiles, so that if you do use change sets (maybe you have contractors doing some work), the risk of deploying extra permissions is reduced.
‍
This is just another example of why working with NaCl is much better than working with XML.