A few days ago, I published a piece in my personal blog about how Salto did the impossible by enabling DevOps and Git for Salesforce CPQ.

‍

‍

The response was overwhelmingly positive, with many readers showing excitement about the possibility of finally treating Salesforce CPQ data as if it was metadata and allowing typical DevOps features such as deployments, Git-based deployments, rollbacks, and more. 

A few readers, though, were quick to point out that this isn't anything new and that it had been done before, to which I 100% agree.

So I thought I would take the opportunity to highlight why Salto's approach fundamentally differs from anything out there and why it is the future of configuration data management. 

‍

Acknowledging the competition

First, I want to acknowledge that Salto is not the first and only software that provides some sort of deployment capability for Salesforce CPQ data.

There are both commercial and open-source solutions, one being the SFDX Data Move Utility, which I've heard from several users that is a good solution for those keen on using SFDX plugins and working with local JSON files.

‍

‍

Regarding commercial solutions, they are a great source of innovation and inspiration, and I fully acknowledge their contributions to the community.

That said, I believe we have something special here at Salto.

‍

It's not just data loading

Many solutions out there focus on loading or migrating Salesforce CPQ data. This is a 100% valid use case, and if your only use case is a one-off data load, then some of those solutions are indeed a great fit.

Our approach, as explained in my other blog post, is to treat Salesforce CPQ data as metadata, which means we can:

• Version it in any Git provider
• Deploy based on the contents of a Git branch (Git-based deployments)
• Rollback changes to CPQ data
• Inspects dependencies (a.ka "where is this used"?)
• Automatically highlight dependencies when deploying
• Deploy it alongside other metadata like custom fields, apex classes, etc.
  ‍

‍

‍

Why treat Salesforce CPQ data like metadata

Because that's what it is; the only reason Salesforce CPQ is configured with custom object records and not metadata is that it's a managed package.

Had it been standard Salesforce functionality, it would be configured via the Setup menu, and all its related configurations could be deployed via change sets, SFDX, etc.

We give Salesforce CPQ data the treatment it deserves by allowing it to benefit from all the features you know and (mostly) love from Salesforce metadata. 

And not only that, we make working with Salesforce CPQ data just like it was metadata; you won’t even be able to tell the difference.
‍

‍

Beautiful comparison visualization

Most solutions out there work with Salesforce CPQ data as JSON files. In Salto, we transform this data into our own language, which we can visualize in a beautiful format.

Here's an example of comparing Salesforce CPQ data in a typical Git provider or another solution:

‍

‍

It's unpleasant to the eye, full of text, and with no awareness of the semantics of the data being represented.

In contrast, the same diff is much easier to read in Salto with our document-like format:

‍

‍

Anyone can read this and quickly understand what's happening, whether it's a Product Owner, QA, Admin, or Developer. 

This makes our solution friendly to anyone on the team, not just developers. 

‍

Impact Analysis ("Where is this used?")

You are probably familiar with Salesforce's "Where is this used?" functionality that allows you to see where custom fields are being used.

In Salto, this functionality is available for standard and custom fields and any other metadata type. 

‍

‍

This is why hundreds of Salesforce customers use our free tier. Yes, this functionality is 100% free. 

But it doesn't stop there, this functionality is also available to Salesforce CPQ data. For example, I can see all the places this Product is being used and what is the impact of making a change to it.

‍

‍

Also, Salesforce CPQ heavily relies on hardcoded field names being the values of other picklists (yuck!), and it's really hard to find those dependencies. With our full-text search, you can easily find those dependencies too.

‍

‍

Other solutions focused on data loading cannot provide this level of insight. 

This leaves your Salesforce CPQ data in a fragile state, where you’d always be wondering if it’s ok to make changes to it, or what will happen if you do. 

‍

A unified approach

Finally, most other solutions have a dedicated product for Salesforce CPQ data loading, which makes sense as it's an entirely different beast than metadata.

At Salto, however, we didn't need to do anything to support Salesforce CPQ data. The same mechanism that allows us to deliver DevOps capabilities for Salesforce, Jira, Zendesk, Okta, and NetSuite is the same one that is used to bring DevOps to Salesforce CPQ.

That means we give you a consistent experience no matter what you are deploying. 

And if you read between the lines, that means that our solution is not limited to Salesforce CPQ. As we speak, we are experimenting with bringing DevOps capabilities to other Appexchange apps, and the results are promising ;)

We are not the same

So with all that said, hopefully, you see now that our approach to working with Salesforce CPQ data is not another iteration of what’s already out there, instead, it is its evolution and the future of DevOps for configuration data.