Skip to main content
All CollectionsSalto for SalesforceGuides
Treat CPQ Data As Metadata And Align Data Across Multiple Orgs
Treat CPQ Data As Metadata And Align Data Across Multiple Orgs

Salto can be used to treat CPQ data as metadata and to align this data across multiple Salesforce orgs. This article describes how to do so.

Support avatar
Written by Support
Updated over a week ago

This article assumes you are familiar with what it means to treat CPQ data as metadata, its implications, and overall configuration. You can read this help article for more information and come back to this one when ready.

Overview

At a high level, the process of using Salto to treat CPQ data as metadata is as follows:

  • Start with recently refreshed sandboxes

  • Select an org to be the source of truth for CPQ data—typically, production

  • Deploy CPQ data from production to all required sandboxes

  • Make changes to CPQ data in any sandbox, deploy to other sandboxes in the pipeline, and, eventually, production.

  • New CPQ data is always created in a sandbox and pushed to production via Salto.

All the sections below assume the process described above is being followed and all the deployment scenarios assume deploying from sandbox to production.

Use a fresh sandbox

If possible, we recommend you use a sandbox that has been recently refreshed or one where you have high confidence that the product and CPQ metadata is somewhat aligned to Production.

Using an old sandbox may result in errors. For example, you may try to deploy Product records that have a value on a field called Created_In_Production__c. If this field doesn't exist in the sandbox you want to seed, the initial deployment will fail.

You can, of course, include the field in your deployment since Salto supports the deployment of CPQ data and metadata at the same time, but this is only going to make aligning your orgs a bit more complex.

For that reason, we highly recommend you use a fresh sandbox.

Enable CPQ in your Salto environments

To fetch your CPQ data with Salto - check 'Include CPQ' when connecting your Salesforce CPQ Org to your new Salto Environment:

Contact support if you wish to customize your Salesforce CPQ connection, or enable it to an existing environment that is already connected to a Salesforce Org without CPQ.

Use deployments to align CPQ data

Once your environments are configured, simply create a deployment from Production to the destination sandbox:

Once the deployment has been created, use the “Type” column filter only to see records of the CPQ package. You can do this by typing SBQQ in the filter text box.

Then just select “(Select All)”—this will select all the SBQQ objects and make them available for selection:

What you do next depends on how you want to align your orgs.

If the destination org is a full sandbox

If the destination org is a full sandbox and was recently refreshed, it most likely already has all the data you need. Also, all the records will have the same Salto ID as their corresponding records in production.

You may, however, want to make sure that you don’t have any missing data in the sandbox. In this case, you can filter the selection table to only see Additions and Modifications.

This will only show the records that don’t exist in the full sandbox or that exist in both orgs, but have some differences. From here on you can select the records you want to align, and continue to deployment.

If your destination org is a developer or partial sandbox

In this scenario, your destination org most likely doesn’t have any CPQ data in it.

In this case, use the “Changes” filter only to include Additions. This will only show the records that don’t exist in the target environment. We are not concerned about Modifications and Removals in this scenario.

Once these 2 filters are in place, the selection table will only show CPQ data that does not exist in the target environment. Now you just have to select the ones you want to deploy:

Dealing with existing data

Regardless of the type of sandbox you are deploying to, it is possible that the sandbox already has some CPQ data in it. There are 2 possible scenarios:

Existing data that also exists in production

Let’s say that you created a Configuration Attribute in production called My configuration attribute. This Configuration Attribute was also created manually in a sandbox before using Salto or created directly in the org.

When you align your orgs, this record will show up twice in the selection table; which might be a bit confusing:

In the screenshot above, the first entry in the table is an addition, and the second one is a removal.

This is happening because even though the 2 records are logically the same, Salto doesn’t know that because their Salto ID is different.

To fix this, you must select both entries, which will cause 2 things to happen when you deploy the data:

  1. The record will be deleted from the sandbox

  2. The record from production will be deployed to the sandbox

From here on, their Salto ID will be aligned and Salto will consider these records to be the same.

You don’t have to delete the second record if for any reason you need it. However, If you don’t delete the second record, you will end up with two configuration attributes in your sandbox that are logically the same. This may or may not be a problem; it’s up to you to decide.

Existing data that doesn’t exist in production

The other scenario is you may have data in the sandbox that doesn’t exist in production, and it was never meant to be in production; this could be data that the owner of the sandbox created for development and testing purposes.

This data will show up as deletions in the deployment table:

This data appears as deletions because we are aligning the orgs. Because the data doesn’t exist in the source environment, aligning the orgs would mean removing this data from the target environment.

You do not have to delete this data. It’s entirely up to you.

If you want the destination sandbox to have the exact same CPQ data as production, and nothing else, then you may delete this data.

If you are ok with this data staying in the sandbox, then you can just leave it there and ignore it.

Finally, if you want this data in production, then you just have to do a deployment from sandbox to production and include this data.

Data created in production without using Salto

As mentioned at the beginning of this article, using CPQ data as metadata implies that all CPQ data in production is created and edited through Salto.

However, we recognize there may be some instances where you have to react quickly and create/edit this data directly in production. If that’s the case, here’s what you need to do:

New data created directly in production

Let’s say you create a Product record in Production. Next time you do a deployment from sandbox to production, this record will appear as a deletion because it doesn’t exist in the source org (the sandbox):

Most likely, this is not what you want to do, i.e., you don’t want to delete the record from production.

To prevent this from happening, you must deploy the product record from production to all relevant sandboxes before your next CPQ deployment.

Just remember this:

You can create data directly in production as long as you deploy it to all relevant sandboxes as soon as possible.

Existing data modified directly in production

The other scenario is where you have a Product record that exists in both sandbox and production, and Salto knows the two records are the same; however, you then modify the record directly in production instead of using a Salto deployment.

In this case, the next time you do a deployment from sandbox to production, you may inadvertently override the changes made in production.

To prevent this from happening, you must deploy the product from production to all relevant sandboxes before your next CPQ deployment.

Like in the previous section, remember this:

You can edit data directly in production as long as you deploy it to all relevant sandboxes as soon as possible.

Beware of dependencies

As you select records to deploy, Salto will let you know if you need to include dependent data. There are 2 scenarios:

Child records

You may select a record that has child records. You don’t need to include them in your deployment, but most of the time, you will want to; this will make sure sample data is as close to its source as possible.

Salto will highlight these records as additional dependencies:

In the screenshot above, the Discount Schedule has child records of the Discount Tier object.

Required dependencies

You may select a record that has a relationship to another record. In this case, Salto will let you know that the other record must be included in your deployment:

In the screenshot above, the Configuration Attribute record is related to a Product Feature record, so the Product Feature must be included if you want to deploy the Configuration Attribute.

Did this answer your question?