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

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

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.

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.

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

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:

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:

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:

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.

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.

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:

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:

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:

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

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.

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.

Continue reading How To Seed A Sandbox With CPQ Data.