Product Category and Attribute
Product Categories
Product Category in Salesforce Revenue Cloud is the object that organizes products into a browsable, governable hierarchy inside a Catalog. Here's the structure first, then why it matters and how you build it.
What is a Product Category?
A Product Category (ProductCategory object) is a node in a tree that groups related products for browsing, governance, and reporting. Key structural facts:
Every category belongs to exactly one Catalog (CatalogId). Categories can nest: a category can have a parent category (ParentCategoryId), which is how "Laptops → Gaming Laptops" subcategories are built — it's a self-referencing hierarchy on the same object, not a separate "Subcategory" object.
Products aren't stored on the category directly — they're linked through the junction object ProductCategoryProduct, which holds ProductCategoryId and ProductId. This many-to-many design lets one product live in several categories at once (e.g., a laptop that's both "Gaming Laptops" and "Back to School Deals").
Why is it required?
Navigation and browsing — categories are what a buyer or sales rep actually clicks through in a storefront or CPQ product search. Without them, a catalog is a flat, unsearchable product list.
Rule targeting at scale — Revenue Cloud lets you write qualification and disqualification rules against a category (ProductCategoryQualification / ProductCategoryDisqualification) instead of every product in it. Say "hide this whole category unless the customer is Enterprise tier" once, instead of repeating the rule per SKU.
Segmentation across teams — RevOps commonly uses categories to separate hardware, software, and services lines within one canonical catalog, so multiple business units share the same data model without duplicating catalogs.
Reporting and rollups — because category membership is structured data, you can roll up revenue, adoption, or usage by category instead of parsing product names or descriptions.
Reuse across channels — the same category tree drives self-service commerce, partner portals, and direct sales quoting, so "how products are organized" stays consistent everywhere.
How is it configured?
A few implementation notes worth knowing:
Declarative, not code-first — all of this is built point-and-click through the Product Catalog Management app; Apex is only needed for custom automation on top of the standard objects.
One category, one catalog — a category can't span multiple catalogs, so if two business units need the same taxonomy, you either share one catalog or replicate the category tree.
Qualification rules run through Decision Tables — ProductCategoryQualification/Disqualification records feed a Qualification Procedure, which Salesforce evaluates against the buyer's context (account, price list, etc.) at browse/quote time.
Categories vs. Product Classification — don't confuse the two: ProductCategory is for browsing/organization, while ProductClassification is a separate object for grouping shared attributes across similar products (both were covered in the earlier catalog diagram).
Setting a default catalog is a quick Setup-level configuration, separate from creating the catalog itself.
Steps:
Make sure you have the Manage Product Catalog permission — that's the permission required to change this setting.
In Setup, search for and open Product Discovery Settings.
Select the catalog you want as the default from the picklist and save.
That's it — no code, no metadata deployment.
Attribute Management
What is a Product Attribute?
In Salesforce Revenue Cloud, product attributes provide a structured way to capture the characteristics or properties of a product and, importantly, make those characteristics usable during product configuration, discovery, qualification, pricing, quoting, ordering, and downstream fulfilment. A Product Attribute represents a characteristic of a product that can be defined, displayed, selected, validated, or used by Revenue Cloud processes.
A useful way to think about them is:
For example,
Laptop’s attributes:
Processor
RAM
Storage
Screen Size
Operating System
Telecom plan attributes:
Download Speed
Data Allowance
Contract Term
Network Type
Insurance product:
Coverage Amount
Deductible
Customer Risk Level
Policy Term
Why do we need Product Attributes?
Without attributes, organizations tend to create separate products for every possible variation. For example, instead of one:
Enterprise Internet you could end up with the product records:
· Enterprise Internet – 100 Mbps
· Enterprise Internet – 200 Mbps
· Enterprise Internet – 500 Mbps
· Enterprise Internet – 1 Gbps
· Enterprise Internet – 2 Gbps
And then create additional products for every contract duration, region, technology and service combination. That quickly becomes unmanageable. With attributes, the catalog can model the product more intelligently:
Product | Attribute | Values | ||
Enterprise Internet | Speed | 100 MBPS | ||
500 MBPS | ||||
1 GBPS | ||||
Contract Term | 12 Months | |||
24 Months | ||||
36 Months | ||||
Network | Fiber | |||
5G | ||||
The product remains one commercial product while its characteristics can vary according to the transaction.
The Attribute Definition vs Attribute Value distinction is extremely important.
Attribute Definition: Defines what characteristic exists.
Example: Internet Speed
Attribute Value: Defines the value selected for that characteristic.
Example: 1 Gbps
Also, another characteristic of Attributes is they can be static or dynamic as well. A dynamic attribute will change according to the transaction context. Its value can be captured or determined during the selling/configuration process and can potentially influence downstream transaction behavior.
Below is a example architecture of how dynamic pricing can be fetched from third party applications and utilized in the sales transaction context.
Making the attribute "dynamic": on the attribute, check Is Price Impacting if it should affect price and mark it visible/required as needed. Revenue Cloud then evaluates the current value at configuration time rather than using a static default.
Driving configuration: attribute values feed Configuration Rules and Qualification Procedures, which show, hide, or require options on the product configurator based on the live value (e.g., hide a component if the ERP feed reports it out of stock).
Driving pricing: price-impacting attributes feed Attribute-Based Price Adjustments, added as an element in the Pricing Procedure, so the quote line price recalculates automatically when the attribute value changes — no manual re-quote needed.
Sync trigger: after the external data lands, a Sync Pricing Data action (or automated flow) refreshes the pricing engine, so the new attribute value is reflected the next time the line is configured or repriced.
The exact object model and terminology can vary by Revenue Cloud release and enabled capabilities, but this is the functional relationship you should use when designing the solution.
How Are Product Attributes Configured?
Step 1 – Define the Business Requirement
Step 2 – Create the Attribute Definition
Step 3 – Associate the Attribute with the Product
Step 4 - Configure Attribute Values
The Quote Configurator screen
Dynamic Attributes Affecting Pricing, In the next articles we will see how we can use attributes to impact the pricing of the product. Also we can add dynamically the Discount when certain criteria is met using dynamic attributes. We can also drive Product Discovery using dynamic attributes which we will cover in a dedicated article.
Comments