This is the final part of the Salesforce Metadata Reimagined series, where I go over some Salto features that completely change the way we interpret and work with Salesforce metadata.

This time, I will talk about our unique approach to Salesforce CPQ and configuration data in general.

What is configuration data

There are two types of data in Salesforce:

‍Standard data: These are data records such as Accounts, Contacts, and Opportunities representing entities your company deals with.

‍Configuration Data: This is data in your Salesforce org that controls the run-time behavior of certain business processes.

Examples of this can be found all over Salesforce CPQ, for example:

• Product Rules
• Option Constraints
• Price Rules
• Error Conditions

The way these records are configured affects how your CPQ logic works. Indeed, CPQ is configured by creating and editing these data records.

‍

‍

Data that wants to be metadata

The problem with Salesforce CPQ data is that this data almost wants to be metadata. Let's look at a concrete example.

Consider the data records needed to create a Product Rule of type validation:
‍

‍

For such a simple requirement, we had to create two data records. For more complex product rules, we could easily have five or more records. If you need 15 different product rules, the number of configuration data records will multiply.

If Salesforce CPQ was standard Salesforce functionality, perhaps many of these rules could be configured with standard validation rules, workflows and flows (and you can still use those, but then you have two frameworks for automating CPQ logic).

But because it's a custom-built application, all the configuration has to be done with data records instead of metadata.

So why is this a problem?

Configuration data cannot be deployed with change sets or via the metadata API. There's no easy way to deploy it across environments while maintaining relationships. There's no standard process to roll back to a previous version or to see the history of this data over time.

Essentially, Salesforce CPQ data is like metadata but without all the benefits of the Metadata API.
‍

It's not just about data loading

As you may have noticed, throughout this series, I acknowledge the existence of other paid and free tools that solve many of the problems related to Salesforce metadata.

In this domain though, most solutions focus on the problem of loading Salesforce CPQ data to other environments and stop there.

To be clear, this is a problem worth solving, and if your only problem with Salesforce CPQ is data loading, those solutions might be a good fit for you.

Our approach is very different and much more encompassing...
‍

Elevating the status of configuration data

At Salto, we translate Salesforce CPQ data to NaCl, the same language we use to describe metadata.
‍

This means that we give configuration data the treatment it deserves: we treat it as metadata. Let's go over a few use cases:
‍

"Where is this used" for Hardcoded fields

Salesforce CPQ heavily relies on using the API name of custom fields on configuration data records. For example, see the below Configuration Attribute:
‍

Because the field name Usable_Capacity__c is simply a string, there's no way for the standard "Where is this used" button to reveal that this field is used here.

What this means is if you change some attribute of this field, you could impact a ton of Salesforce CPQ configuration data, and you wouldn’t know until the logic fails at run-time.

This is not a problem in Salto because you can simply search for the field API name and we'll reveal its usage, whether its metadata or configuration data:
‍

The same applies to any Salesforce CPQ object that has SBQQ__TargetField__c and SBQQ__TargetObject__c fields. You can find where these fields and objects are used by doing a simple text search.
‍

Impact Analysis

We can also perform impact analysis on Salesforce CPQ data. Let’s say we want to see where a Product is being used or referenced. This information is just one click away:
‍

In the above example, we can see that the Bass Guitar Product is used in two Product Features and four Product Options.

Data and Metadata Deployments

With Salto, we can deploy metadata and configuration data in the same deployment, without having to specify which is which.You can also see the difference between the source and target environment which will give you the confidence you are only deploying the intended changes.
‍

Smart deployments

On the same topic of deployments, Salto will let you know if a CPQ data record you are trying to deploy is missing a related element, such as another record on a lookup field.
‍
For example, if you select a Configuration Attribute, Salto will automatically show you which Product that attribute is related to so that you can include it in your deployment.
‍

This way, we help you build a deployment plan that will work on the first try.
‍

Metadata Comparison

In our free tier, you can compare two instances of a metadata type. This also works for configuration data. For example, let's say you have two Product records that look very similar, and you suspect they are duplicates.

Using our metadata comparison, you can quickly see the differences.

Versioning

Since we treat configuration data as metadata, you can also version it in Git. Imagine being able to create a pull request and see the changes to your Salesforce CPQ data before deployment.
‍

‍

More than just CPQ

The approach I showed here can also be extended to any other configuration data in your Salesforce org, such as a custom pricing engine or a lead routing solution.

If it’s configuration data, we’ll treat it as metadata :)