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 for deploying all your CPQ configuration. See our Gearset for CPQ documentation for more information.

The Gearset data loader detects referenced objects and brings related records into the deployment, but this referencing only works in one direction.

Let’s see the implications of this when deploying CPQ data:

Overview:

For more information about CPQ we suggest completing this trail on Trailhead.

When we select Product in the Gearset data loader configuration, we might also expect Gearset to deploy the related Product Options, Product Features, Configuration attributes etc.

Unfortunately, this won't work as we'd expect. When Gearset deploys dependencies, it follows lookup fields to find those dependencies. Product doesn't have these lookup fields. The lookup fields are on Product Option, Product Feature and Configuration Attribute, pointing to Product, rather than from Product. So selecting Product at the top level will not deploy the rest of the object that we are interested in, because the tool will not be able to detect them.

Product is the “root” because it doesn't point to any further objects we're interested in. We need to select all the “leaves”, which are the objects we're interested in that don’t have any other object pointing to them. Gearset will follow the lookup fields all the way to the root and deploy all the records we wanted. For each selected object the system will show on the right side the direct lookup dependencies.

If we consider only the standard objects in the first screenshot, we would select as top level objects: Product Attribute set, Attribute Item and Product Option. The dependency analysis will bring in the related Attribute Set, Configuration Attribute, Product Feature and Product.

However, by selecting Attribute Item, we will bring in only the Configuration Attributes that have an Attribute Item (which are the global attributes). But not all the configuration attributes are global attributes, and we don’t want to leave the “normal” attributes out of the deployment. For this reason we need to add the Configuration Attribute object as a top level selection. There is no need to make adjustments for Product Features, because all features have a Product Option, so we are not leaving records out. The same is valid for Attribute Sets.

For the purpose of this deployment, we don’t need to deploy all records in the Product object, so we are keeping it out of the top level selection too. In general, we need to keep this chain of lookups in mind to understand if we are leaving records out of the deployment.

You can use any field in the selected top-level object as a filter field. For example, for Product Option you can use Configured SKU or Optional SKU to filter the records. If you need to filter based on a field present on a related object (for example filter Product Option based on a field in Product), you will need to create a formula field on Product Option. You can read further about this in this article: the relevant section is “How can I filter the deployment to records belonging to specific accounts?”.

Product Rules help sales reps stay on course when navigating complex combinations of products and services. A product rule record has a few details about how the rule should behave, but mainly it acts as a container, or point of contact for any records on the other objects related to the rule:

A product rule can technically be deployed without related records, but it won’t do much. On the other hand, some of the related objects cannot be deployed without the related product rule due to the Master-detail relationship (the red line in the picture above).

To deploy Product Rule we will select the leaves: Configuration Rule, Error Condition, Product Action, and Lookup Query. This will bring in the reference fields from Summary Variable, Product Rule and Product.

Bear in mind that these are only the core objects, and you might need to add others based on your data model. For example Lookup queries tie a product rule to an object that houses the data set that drives the behavior of the rule. If this data set has changed, the object that contains it needs to be added to the deployment at the top level.

Similarly to Product Rule, Price Rule mainly acts as a container for any records on the other objects related to the rule.

To deploy Price Rules we should select Lookup Query, Price Action, and Price Condition at the top level. This will bring-in the reference fields from Summary Variable and Price Rule. In the next step of the configuration we will be able to select any Products that have a Price Rule, as an indirect relationship to the top-level items selected.

A common error when deploying Product Rules and Price Rules is CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY.

When the field Conditions Met is set to Custom in the rule we are trying to deploy, an Apex trigger enforces that the conditions used in the Advanced Condition field must exist. This leads to a circular dependency. We can't create the conditions if the rule doesn't exist. We can't create the rule with Conditions Met set to Custom if the conditions don't exist.

To break this circular dependency, Gearset creates the rule without setting the Conditions Met field. Gearset then updates Conditions Met later in the deployment. If there isn't a default value for Conditions Met then the deployment will fail.

In the target org, set the default value for Conditions Met field to All or Any, on the Product/Price rule object.

During the deployment, Gearset will create the rule using the default value. The conditions on the rule are then created. Finally, we update the rule to use the correct value for Conditions Met.