The sandbox seeding add-on and CPQ
Antonio Sale avatar
Written by Antonio Sale
Updated over a week ago

ANNOUNCEMENT: This article describes how to deploy CPQ with our sandbox seeding add-on. Our new Gearset for CPQ deployment solution is now our recommended product. See our documentation for more information.


CPQ (or Configure Price Quote) allows sales teams to generate quotes for products through the Salesforce UI. To create a quote you must first choose products, some of which are required to be sold together. For this reason a central concept is the bundle, which is simply a group of products we know should be sold together.

When the sales rep chooses to sell the bundle, the product configuration interface brings in all the related products. When the Product Configuration page loads, what we see is really a page built from records—Product records, Option records, and Feature records. The configuration page itself is not actually a record, so the configuration page is not an object with its own fields.

Pre-deployment steps

CPQ consists of both metadata and data, so before running a data deployment, you should first align the source and target metadata to make sure that all the necessary containers (metadata) are there to receive the deployed records (data). You can do so easily by running a metadata comparison using Gearset.

Please also note that data deployments in Gearset are disabled by default. To enable data deployments, a team owner must manually enable them via the account page in the app. When you enable the data loader, deployments to Production will also be disabled by default, and can similarly be enabled by a team owner via the account page.

Data Deployment Configuration

Once you have selected a source and target, Gearset will perform a Salesforce listMetadata call to retrieve the object list from the two orgs, and display the results in a tree view. A data deployment configuration in Gearset has 3 steps.

Step 1 - select the top-level objects for your data deployment

Top-level objects are ones that Gearset will use as a starting point to analyze your data model. This selection of the top-level objects depends on the objective of your data deployment. At this stage you can choose to use the object filter settings to specify which records you would like to deploy by field value. You can also use complex filters to retrieve a specific subset of records.

Once you select a top-level object, you will see any referenced objects automatically detected by Gearset. The Schema Builder in Salesforce (from Setup) is a handy tool for explaining the direction data flows through your system, allowing you to visualize the relationship between objects.

Object relationships are a special field type (the lookup or the master-detail) that connect two objects together. The Gearset data loader detects referenced objects and brings related records into the deployment, but this referencing only works in one direction.

Step 2: Indirect dependencies and matching existing records.

At this second step of the configuration, Gearset will traverse the dependency graph to determine any further indirect dependencies necessary to deploy records from the selected objects. You will also be able to define how to match existing records.

On the left-hand side are the top-level objects that you selected in the previous step. On the right side are all the direct and indirect dependencies.

For each object, you can choose to upsert records by selecting an external ID field. The ID field must be specified as an "external ID" or "lookup ID" field within Salesforce. If no such fields exist on the object, no matching of existing records will occur - all records will be inserted into the target as new.

If you are deploying between 2 related orgs you might be able to upsert based on the SalesforceID.

This will be available if:

  • source is backup and target is the original org

  • source is a sandbox, target is a sandbox, they’re sandboxes of the same org

  • source is a prod org, target is a sandbox, target is a sandbox of the source org

However, if you are deploying from an org to a non-related one you will need to create an External ID field.

CPQ objects often use a randomly generated field to identify new records (for example the Name field of a Product Option record will be a randomly generated sequence, such as PO-000076). Unfortunately randomly generated fields cannot be used as external IDs, as they cannot be created by users.

On several forums online, other Salesforce users have suggested a workaround: create a new text field (marked as External ID) and have an automated script copy and paste the number randomly generated by Salesforce into this new field.

Let's use Product Option as an example. If we deploy from an org to its sandbox, we may be able to upsert based on SalesforceID. If we are deploying between 2 unrelated orgs, the Salesforce ID would not be available for upsert. In this case we need to have an External ID field. The best field for this would be the Name field, which is unique. However, this is a field managed by Salesforce, and it is populated with a random generated text. This type of field cannot be used as an External ID for matching records. Moreover, as it's auto generated by Salesforce, the record PO-000076 in the source would be assigned to a different number (for example PO-000089) in the target, and this number cannot be modified (i.e. updated with the name that you want).

Without another field for matching the two records, at every deployment you will create duplicate records because the random name will not be matched between source and target.

In the example below we created an External ID field (Unique ID) and populated this field by simply copying and pasting the randomly generated Option Name field.

After the deployment to the target, even if Salesforce assigns a different number to the record in the Name field, the Unique ID will keep track of what was the original name and match the records.

Not all CPQ objects will require a new External ID field. When you see only create new records as an option for matching, this means that no such existing External ID field exists. If creating new records is not the desired outcome, it will be necessary to create an External ID.

Step 3 - The deployment plan and templates

The deployment plan is a collection of steps we run to move data from the source to the target. It is also at this stage that it is possible to create a configuration template.

Data Deployment Templates save you time when setting up a new data deployment, and ensure that the same data configuration is used every time. Once you've configured a CPQ data deployment, you're able to save the configuration for that deployment as a new template (using the box at the bottom of the summary page).

You can also save a template from a completed deployment. Creating a template from a deployment configuration will save:

Selecting one of those templates will apply a previously saved configuration to your new data deployment (to replicate, for example, a Product bundle deployment). If you're not entirely happy with the configuration from the template, then you can still make changes to the deployment (but those changes won't update the selected template).

In some cases, objects or fields from the template may not exist. When Gearset can't use the full configuration from the template it will apply as much of the template as possible:

  • Objects or fields in the template that don't exist in the target won't be included

  • If external ID fields in the template don't exist, Gearset will default to the same field it would use if you weren't using a template. If there are no External ID fields this might be switched to “Create new records”.

Gearset can also disable validation rules and triggers for you before you start your data deployment.

Did this answer your question?