Salto allows you to manage CPQ data (products, configuration attributes, etc.) as if it was 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.

Note the emphasis on the word allows. You can use Salto for CPQ for other use cases, such as seeding a sandbox with sample data. Treating CPQ data as metadata is a choice, and it 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: its name.

If you have an apex class named UnitOfWork in both your sandbox and production environments, these 2 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.

This is also the case when using Salto for CPQ; there are no out-of-the-box methods that Salto can use to identify two records in different orgs as the same.

What’s needed is an ID that Salto can use on both products 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 more.

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.

In this mechanism, the Salesforce ID of your production environment is used as a Salto ID. This is perfect when using CPQ data as metadata, as described in the previous section.

In this mechanism, you must create a cpq_external_id__c field on every CPQ object that you want to manage with Salto. You are responsible for populating this field with a unique value. Salto will then use the value in this field to match records across environments.

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 2 records to be the same.

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

This method is meant to be used when Production is considered the source of truth for CPQ data, and you want to manage CPQ data as metadata; again, that means that:

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 2 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 mind-bending, 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.

Now, as explained above, this is only one of three methods Salto offers for matching data across environments, and while this is the default and recommended one, it’s important that you are aware of its pros and cons:

Let’s now move on to the next mechanism.

This method is also meant to be used for treating CPQ data as metadata. Here, you must create a unique text field marked as an external ID in all the CPQ objects that you want to manage through Salto.

Salto does not provide a method to populate these records with a unique value in this field. You are responsible for creating such a mechanism, which is typically done by creating a batch apex job that goes through these records and stamps that field with a unique value.

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.

Here are the pros and cons of this approach:

To enable this mechanism, please contact support.

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 3 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.

Here are the pros and cons of this approach:

This method is considered suboptimal to the previous two; however, you can still use it if you want.

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

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

The Salesforce Record ID method stands out for its simplicity and out-of-the-box functionality, making it our top recommendation for those treating CPQ data as metadata. It offers predictability, replicability across sandboxes, and minimal setup.

Using an External ID is also a viable choice, particularly for those seeking high flexibility and control. Although it requires more setup and maintenance, it allows you to have complete control over what constitutes a Salto ID.

On the other hand, while the field values-based IDs offer a degree of flexibility, they are more prone to conflicts and may lead to unexpected changes to Salto IDs. Therefore, it's less ideal unless the specific use case warrants this approach.

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:

And here’s what Salto recommends you use each method for:

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