Salesforce metadata reimagined—a unique approach to org comparison

Written by
Pablo Gonzalez
Business Engineering Architect
February 3, 2022
min read

Table of Contents

View all guides


Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.

This is some text inside of a div block.

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.

Get started with Salto

Track critical changes to your Salesforce orgs

Try Salto free ≥

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.

Understand the impact of every change in your org

Try Salto free ≥

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.

Written by
Pablo Gonzalez

Pablo is a Business Engineering Architect at Salto. He is the developer of and has 11 years of development experience in all things Salesforce.

Written by