Salto allows you to manage CPQ, sbaa and blng data (products, product rules, configuration attributes, approval rules etc.) as if it were metadata. That means you can compare and deploy it across environments, visualize dependencies (a.k.a “where is this used?”), and keep track of its history with Git.
​
Treating CPQ data as metadata typically means that:

If you want to treat CPQ data as metadata, then you must become familiar with how Salto manages CPQ records and the different options you have for specifying how records are matched across Salesforce environments.

Salesforce metadata can easily be deployed to other orgs because it has a unique ID: the api name.

For example if you have an Apex Class named UnitOfWork in both your sandbox and production environments, these two classes are considered to be the same. They can be updated/deployed via Change Sets, SFDX, or the Salesforce API, which is the method utilized by Salto.

However, this principle does not apply to CPQ data and Salesforce data in general. For instance, If you import a product record with the data loader to your sandbox and repeat the upload to your production org, Salesforce doesn’t automatically recognize that these two records are the same, they will have a different id.

What’s needed is an identifier that Salto can use on both records so that when you do a “compare and deploy” operation, Salto can tell they are the same. This will allow you to align CPQ data across environments and release changes on those records across your pipeline.

Salto provides three mechanisms for specifying how records are matched across environments. Let’s review the three mechanisms at a high-level first, followed by an in-depth explanation of each.

This mechanism relies on a dedicated external ID field for every CPQ object that you want to manage with Salto. This field must be populated with a unique value (our customer success team can help you with this - please reach out). Salto will then use the value of this field to match records across environments.

This mechanism requires zero extra setup and relies on the record ID assigned by Salesforce. Initial alignment between existing environments can be somewhat complicated and it is recommended to establish a single source of truth in which new records are added.

In this last mechanism, the Salto ID is generated by concatenating multiple field values from your CPQ records. For example, the Product Code, Product Family, and Name fields are concatenated to create a Salto ID. If the same combination exists in another Salesforce org, Salto considers these two records to be the same.

Now, let’s explore these three mechanisms in detail, along with some guidelines on when to use each.

The first step is to create a unique text field marked as an external ID for all the CPQ objects that you want to manage through Salto. This field can have any name.

You can either roll out your own solution for populating these records with a unique value in this field or reach out to Salto support for assistance with this one time process.

The unique value can be anything you want; it can be the Salesforce ID or the Salesforce ID plus other field values, etc.

Once the ID is in the record, Salto will treat it as the Salto ID, and all Salto operations will behave as expected when a record in another environment has the same Salto ID.

Our team is happy to help you set up this mechanism. If you want to set it up yourself, configure an external ID field in Salesforce as described and update your Salesforce configuration file in Salto to match the example (replacing Salto_ExternalID with the name you chose for your field):

This method requires zero setup in Salto but is relatively difficult to align between environments and can be brittle.

Let’s see what this looks like in practice:

I have this product record in my production org:

And I’ve fetched it into my Salto production environment:

When I hover over its name, I can see the Salto ID is 01t3H000003FaZgQAK:

This is the same ID that you can see in the Salesforce URL in the first screenshot.

That means the Salesforce ID is used as the Salto ID: a unique string to identify this record across other Salesforce environments.

Using Salto, I have deployed this product to my sandbox. When I look at the product in my Salto sandbox environment, I see that the Salto ID is exactly the same:

This means that as far as Salto is concerned, these two products are the same.

But what about the actual Salesforce ID in the sandbox? It’s not the same:

And this is expected: when you deploy data to other Salesforce orgs, Salesforce generates the IDs on the fly, and you have no control over it.

This might be a little confusing, so let’s summarise it with a table:

As you can see, the Salesforce ID of the record in production is used as the Salto ID for both Salto environments, and it doesn’t matter that the Salesforce ID in the sandbox is different; Salto only cares about the Salto ID.

The final method creates a Salto ID by concatenating field values from a record, where it is assumed that the result of this concatenation will be a unique value.

Let’s say you have a product record with the following field values:

You can configure Salto to use these three fields to create a Salto ID, which would result with Laptop_Electronics_004. If another product is found in another org with the same field values, its Salto ID will be the same, and Salto will consider them to be the same record.

Salto provides a default configuration for all standard CPQ objects and the fields that determine the ID. You can, however, modify this configuration or come up with your own. Contact support for more details on enabling this option.

In conclusion, Salto offers three distinct methods for managing CPQ data: External ID, Salesforce Record ID, and field values-based IDs.

Each method has its unique merits and drawbacks, tailored to cater to different circumstances.

Using an External ID is our recommended approach for flexibility and maintainability over time. Though it requires some effort to set up at first, once your Salesforce environments are onboarded you shouldn't have to think about record IDs ever again. You can also tailor this solution in a way which fits your organization.

The Salesforce Record ID method is simple and works out-of-the-box, though can start to raise issues over time. If you are looking to get up and running quickly or have a targeted project (such as a one time data migration or seeding) this may well be the solution for you.

The field values-based IDs offer a degree of flexibility, but are more prone to conflicts and may lead to unexpected changes to Salto IDs. Therefore, we recommend you try this approach only if you have a specific need that it addresses.

Choosing the right method ultimately depends on your specific needs, the resources available for setup and maintenance, and your long-term data management strategy.

Here is a summary of the three approaches:

Continue reading how Salto can be used to treat CPQ data as metadata and to align this data across multiple Salesforce Orgs.