Cpq Product Catalog Setup

CPQ Product Catalog Setup

Use this skill when configuring the Salesforce CPQ product catalog: building product bundles, defining product options and features, creating product rules (Validation, Alert, Selection, Filter), and setting up configuration attributes that drive dynamic bundle behavior. This skill does not cover standard Salesforce Products & Pricebooks, CPQ pricing rules, discount schedules, or quote document templates.

Before Starting

Gather this context before working on anything in this domain:

• Confirm the Salesforce CPQ managed package (SBQQ__) is installed and licensed in the org. CPQ product objects (SBQQ__Product2__c, SBQQ__ProductOption__c, SBQQ__ProductRule__c) will not exist without it.
• Identify the bundle parent product and all child products that will appear as options. Determine which options are Required, Optional, or Default-selected.
• Understand the nesting depth planned. Salesforce CPQ supports bundle nesting up to 4 levels, but each level multiplies configurator load time — deep nesting is a performance risk.
• Clarify whether the bundle needs dynamic filtering. Filter rules and configuration attributes add setup complexity but are the correct mechanism for attribute-driven option visibility.
• Understand rule ordering requirements early. Product Rules fire in sequence number order, and Selection rules can interfere with one another if sequenced incorrectly.

Core Concepts

Product Bundles and Product Options

A CPQ product bundle consists of a parent product and one or more child products registered as SBQQ__ProductOption__c records linked to the parent. Options are organized into SBQQ__Feature__c records, which control how they are grouped and displayed in the CPQ configurator UI.

Each Product Option carries key configuration fields:

• SBQQ__Type__c — Component (priced individually), Bundle (nested bundle), or null. Drives how the option is quoted.
• SBQQ__Required__c — Boolean. When true, the option is always included and cannot be removed.
• SBQQ__Selected__c / SBQQ__Default__c — Controls whether the option is pre-selected when the configurator opens.
• SBQQ__MinQuantity__c / SBQQ__MaxQuantity__c — Enforces minimum and maximum selection counts per option.
• SBQQ__Number__c — Sort order within the feature.

Bundles can be nested: a Product Option can itself be a bundle product. The CPQ configurator supports up to 4 nesting levels, but each nested level triggers additional SOQL queries at configurator open, meaning 4-level nesting on large catalogs can exceed governor limits or cause multi-second page loads.

Product Rules

Product Rules (SBQQ__ProductRule__c) enforce business logic in the CPQ configurator. There are four types, each with distinct behavior:

Rules are composed of:

• Conditions (SBQQ__ErrorCondition__c) — evaluated against quote line fields or product option fields
• Actions (SBQQ__ProductAction__c) — what to do when all conditions are true (for Selection and Filter rules)

Product Rules fire in ascending order of their SBQQ__Sequence__c field. For Selection rules that chain (rule A's action triggers rule B's conditions), sequence order is the only control mechanism. Misconfigured sequences cause infinite loops or missed selections.

Configuration Attributes

Configuration Attributes (SBQQ__ConfigurationAttribute__c) are header-level fields displayed at the top of the CPQ configurator, outside of individual product lines. They allow bundle-level choices — such as "Service Tier" or "Region" — to drive Product Rule conditions without being tied to a specific option.

Configuration Attributes are scoped to a specific bundle product. When an attribute value changes, CPQ re-evaluates Filter rules and Selection rules that reference that attribute. This is the correct mechanism for attribute-driven dynamic bundles; attempting to replicate this with custom fields on the product record is not supported and will not trigger rule re-evaluation.

Common Patterns

Pattern: Simple Required/Optional Bundle

When to use: The bundle has a fixed set of required components (always included, always priced) and a set of optional add-ons the customer can select.

How it works:

1. Create the parent product record. Mark it as a Bundle in CPQ (SBQQ__Component__c = false, SBQQ__QuantityEditable__c as needed).
2. Create a Feature for each logical grouping (e.g., "Hardware", "Software", "Services").
3. Create Product Option records linking each child product to the parent, setting SBQQ__Required__c = true for mandatory components and SBQQ__Selected__c = true for default-selected optionals.
4. Set SBQQ__MinQuantity__c and SBQQ__MaxQuantity__c on options where selection limits apply.
5. Test in the CPQ configurator by adding the bundle to a quote.

Why not the alternative: Using Validation rules to block deselection of required components is fragile — a required option should be marked Required at the Product Option level, not blocked post-hoc by a rule. Validation rules add page load and save overhead unnecessarily.

Pattern: Dynamic Bundle with Filter Rules and Configuration Attributes

When to use: The set of visible options should change based on a header-level choice the rep makes at bundle configuration time (e.g., choosing "Enterprise" service tier reveals premium add-ons not shown for "Standard" tier).

How it works:

1. Create the parent bundle product and all possible options as Product Option records (including options that will initially be hidden).
2. Create a Configuration Attribute linked to the parent bundle, mapping it to a custom field on the Quote Line (SBQQ__QuoteLine__c) or Product Option that will hold the attribute value.
3. Create a Filter Product Rule with conditions that evaluate the Configuration Attribute field value and actions that include or exclude specific options.
4. Set the Filter rule's SBQQ__Scope__c to "Product" to target options within the bundle.
5. Test by opening the configurator, changing the attribute value, and confirming the option list re-renders correctly.

Why not the alternative: Custom Lightning Web Components or JavaScript customizations to hide options are fragile across CPQ managed package upgrades. Filter rules are the supported, upgrade-safe mechanism for attribute-driven option visibility.

Decision Guidance

Recommended Workflow

Step-by-step instructions for an AI agent or practitioner working on this task:

1. Confirm CPQ installation and license. Verify SBQQ__ objects exist in the org schema. Check that the user has CPQ product configuration permissions. Without the managed package, no CPQ product setup is possible.
2. Map the bundle structure. Document the parent product, all child products, their Feature groupings, and which options are Required, Default-selected, or Optional. Identify nesting depth. Flag any planned nesting beyond 2 levels for performance review.
3. Create Features and Product Options. Create Feature records for each option group. Create Product Option records for each child product, setting Type, Required, Selected, Min/Max Quantity, and sort order. Do not proceed to rules until the base bundle is tested in the configurator.
4. Define and sequence Product Rules. Identify all business constraints. Map each constraint to a rule type (Validation, Alert, Selection, Filter). Assign sequence numbers deliberately — Selection rules that chain must be sequenced so earlier rules do not undo later ones. Create Conditions and Actions for each rule.
5. Configure Configuration Attributes if needed. If any product rules depend on header-level choices, create Configuration Attributes linked to the bundle and the relevant field. Validate that changing the attribute value triggers the expected Filter or Selection rule behavior.
6. Test in the CPQ configurator end to end. Add the bundle to a test quote. Test all rule branches: required options appear, incompatible options are blocked on save, auto-select fires correctly, and filter rules re-render on attribute change.
7. Document rule sequences and attribute mappings. Record the purpose and sequence number of every product rule. Undocumented rule sequences become maintenance liabilities, especially when new rules are added later.

Review Checklist

Run through these before marking work in this area complete:

• All Product Option records have correct Type, Required, Selected, and Min/Max Quantity values
• Feature records are created and options are assigned to the correct feature with correct sort order
• Product Rules have explicit sequence numbers and the sequence order is documented
• Each Product Rule has at least one Condition and (for Selection/Filter rules) at least one Action
• Configuration Attributes are scoped to the correct bundle product and linked to the correct field
• Filter rules have been tested with attribute value changes in the configurator
• Bundle nesting depth is 3 levels or fewer, or a performance exception has been documented
• Validation rules have been tested by attempting to save a quote that violates each condition

Salesforce-Specific Gotchas

Non-obvious platform behaviors that cause real production problems:

1. Bundle nesting beyond 2 levels multiplies configurator load time — Each nested level triggers additional SOQL queries when the configurator opens. At 4 levels with a large catalog, page load can exceed 10–15 seconds or hit anonymous apex governor limits. Flatten nested bundles wherever possible.
2. Product Rules fire in sequence number order — duplicates or gaps cause unpredictable behavior — If two Selection rules share the same sequence number, CPQ's evaluation order between them is undefined. Always use unique, spaced sequence numbers (10, 20, 30) to allow insertion without renumbering.
3. Configuration Attributes are bundle-scoped, not product-scoped — An attribute defined on Bundle A does not carry over when Bundle A is nested inside Bundle B. Each bundle level that needs attribute-driven behavior requires its own Configuration Attribute setup.
4. Filter rules hide options in the UI but do not prevent API-level additions — If a record is inserted via the SBQQ API or via a Salesforce Flow outside the configurator, Filter rules are not evaluated. Validation rules are required to enforce constraints that must hold at the data level.

Output Artifacts

Related Skills

• products-and-pricebooks — Use for standard Product2 and Pricebook2 setup before adding CPQ-specific configuration
• cpq-vs-standard-products-decision — Use to determine whether CPQ is the right tool before beginning CPQ product setup
• quote-to-cash-requirements — Use during requirements gathering to confirm which CPQ capabilities are needed