Gearset automatically sequences the data and metadata in a single deployment, so most teams never need to think about ordering. (For a refresher, see how Gearset sequences deployments automatically.)
However some teams choose to break a large bundle into smaller, staged deployments. This might be, for example, to keep change sets reviewable, to deploy a complex bundle in stages, or to fit an established release process.
When you split a bundle by hand, you take on the sequencing yourself, so the objects need to go across in dependency order. This guide gives you a repeatable, three-stage pattern for a single bundle, organized around the bundle's Product Classification.
When you need this: only when you deliberately split one bundle's configuration data across separate deployments. If you deploy a bundle in a single comparison, Gearset handles the ordering for you and you can skip this guide. |
Before you start
Make sure the following are in place, so that your records map cleanly across orgs:
You've run the External ID wizard on your source and target orgs, so Gearset can track records as they move between environments.
Your External IDs are aligned. If a comparison returns unexpected results, align your IDs using the Gearset template before you continue.
You know the Product Classification name of the bundle you're deploying. Every filter below is built around it.
How the staged approach works
The pattern uses three saved comparison filters, deployed in order. Each stage builds on the one before it, so a record's parents and dependencies are always already in the target org by the time the record itself is deployed:
Stage 1 - classification and attributes. The Product Classification, its attributes, and the related picklists, categories, and attribute-based adjustments.
Stage 2 - products. The products built on that classification, along with their attribute definitions, selling model options, and component groups.
Stage 3 - relationships, categorization, and pricing. The records that connect products together and to the catalog, plus price book entries.
Deploy stage 1 in full, then stage 2, then stage 3. Within each stage, Gearset still sequences the individual records for you and you're only controlling the order between stages.
A note on Product Classification name. All three filters key off the bundle's Product Classification name. Before you run each comparison, open the filter and update the SOQL, replacing <Classification name> with the name of the bundle you're deploying. Save the filter as a team filter so the whole team can reuse it. |
Stage 1 - classification and attributes
This stage deploys the Product Classification together with its attributes and everything those attributes depend on. Use SOQL on the objects that relate directly to the classification, and follow the click paths for the objects that don't.
Object | Query or click path | Notes |
ProductClassification | WHERE Name = '<Classification name>' |
|
ProductClassificationAttr | WHERE ProductClassification.Name = '<Classification name>' |
|
AttributeDefinition | ProductClassificationAttr → Depends on → AttributeDefinition |
|
AttributePicklist | ProductClassificationAttr → Depends on → AttributeDefinition → Depends on → AttributePicklist |
|
AttributePicklistValue | ProductClassificationAttr → Depends on → AttributeDefinition → Depends on → AttributePicklistValue |
|
AttributeCategory | ProductClassificationAttr → Depends on → AttributeCategory | You can also find these by searching the bundle name on the AttributeCategory tab |
AttributeCategoryAttribute | ProductClassificationAttr → Depends on → AttributeDefinition → Related → AttributeCategoryAttribute | These can't be isolated, so you may select some from another bundle. Those errors are safe to ignore |
AttributeBasedAdjustment | WHERE Product.BasedOn.Name = '<Classification name>' |
|
AttributeAdjustmentCondition | WHERE Product.BasedOn.Name = '<Classification name>' |
|
AttributeBasedAdjRule | AttributeAdjustmentCondition → Depends on → AttributeBasedAdjRule |
|
Indented objects are reached through Gearset's Depends on and Related expanders in the comparison results, rather than through their own query. Attributes are the most involved part of this stage, so expect to expand several levels below ProductClassificationAttr to gather every record.
Stage 2 - products
Once stage 1 is live in the target org, deploy the products built on the classification, along with their definitions and selling options.
Object | Query or click path | Notes |
Product2 | WHERE BasedOn.Name = '<Classification name>' |
|
ProductAttributeDefinition | WHERE ProductClassificationAttribute.ProductClassification.Name = '<Classification name>' |
|
ProductSellingModelOption | WHERE Product2.BasedOn.Name = '<Classification name>' |
|
ProductComponentGroup | WHERE ParentProduct.BasedOn.Name = '<Classification name>' |
|
Stage 3 - relationships, categorization, and pricing
With the classification and products in place, deploy the records that link products together, slot them into the catalog, and price them.
Object | Query or click path | Notes |
ProductRelatedComponent | WHERE ParentProduct.BasedOn.Name = '<Classification name>' OR ChildProduct.BasedOn.Name = '<Classification name>' |
|
ProductCategoryProduct | WHERE Product.BasedOn.Name = '<Classification name>' |
|
ProductCategory | ProductCategoryProduct → Depends on → ProductCategory |
|
ProductCatalog | ProductCategoryProduct → Depends on → ProductCategory → Depends on → ProductCatalog |
|
PriceBookEntry | WHERE Product2.BasedOn.Name = '<Classification name>' |
|
ProductConfigFlowAssignment | WHERE ProductClassification.Name = '<Classification name>' | Rarely needed — most bundles use existing records |
ProductConfigurationFlow | ProductConfigFlowAssignment → Depends on → ProductConfigurationFlow | Rarely needed — most bundles use existing records |
Most bundles reuse existing configuration flows, so ProductConfigFlowAssignment and ProductConfigurationFlow are rarely needed. Include them only if your bundle uses its own flow.
Tips for a smooth deployment
Build each filter once, then reuse it. Save the three filters as team filters and update only the classification name each time. That's what makes the process repeatable across bundles.
Some attribute records can't be isolated. When you gather AttributeCategoryAttribute records, you may pick up a few that belong to other bundles. Any resulting errors are safe to ignore.
Let Gearset check each stage. After you select components, Gearset assesses the deployment and suggests fixes for missing dependencies. Then review and apply these before deploying.
If a comparison looks wrong, check your IDs. Unexpected results usually mean your External IDs are out of sync.