Mastering Product Setup in Revenue Cloud Advanced
Revenue models today are increasingly complex, companies rarely going to market with a one-size-fits-all approach. The upside of this complexity promises significant gains in revenue and customer experience, which is great! But there are also downsides, namely around the challenges in operationalizing these more sophisticated strategies.
Enter Salesforce’s Revenue Cloud Advanced (RCA), a significant leap forward from the traditional CPQ platform in its ability to handle the complexity of modern pricing and packaging. But just like any other powerful tool, its value will come down to how you use it. After all, hammers can both drive in nails and also punch holes in walls.
For us at Cloud Giants, it's that successful use of the tool we aim for, and the goal that prompted us to create this guide; even for us experienced CPQ-ers and with Salesforce providing its own RCA glossary, RCA represented a disorienting learning curve, with so many pieces to put together. Here, we break down the building blocks of RCA’s Product Catalog Management to advise us all in how to best design and deliver product solutions. We hope it accelerates your learning curve too.
CONTENTS
> General RCA Administration
> Product Setup
> Attributes
> Catalogs and Configuration
General RCA Administration
Before diving into the weeds, let’s start a few more global concepts that are critical to understand overall:
Modular Architecture
For CPQ vets just now learning RCA, much of what you should expect is a shift to a “heavier” and more modular object scheme. Commonly, this means what used to be a picklist is now a new object and related junction object (e.g., Pricing Method + Subscription Term picklists → Product Selling Model object + Product Selling Model Option junction).
In doing so, Salesforce has increased complexity of the model, a tradeoff which can pay huge dividends in terms of flexibility and repeatability - empowering revenue operations and in many ways decreasing the cost to administer.
Dynamic Revenue Orchestration
This is an extensive topic we won’t cover here in full, but it does impact product design. Specifically, it separates the Product you Quote vs. the Product that gets Ordered, allowing you to offload complexity from the product catalog into orchestration logic. You don’t need to model every product permutation or component in advance!
For example, let’s imagine a company sells Cloud Hosting, but the fulfillment process is different if the customer is based in the US vs. the EU. Previously, this may have required two separate SKUs; with DRO, there can instead be a single “Cloud Hosting” commercial product available in the catalog.
Revenue Settings & Salesforce Pricing
CPQ’s global settings were managed via its Installed Package. RCA’s proxy for this is now found within the normal setup menu under “Revenue Settings” or “Salesforce Pricing Setup”. Go here to enable and control much of the functionality shown below.
Sync Pricing Data
CPQ vets know that “Run Post-Install Scripts” was the equivalent of “blow on the Nintendo cartridge” whenever they got a weird error. Sync Pricing Data is RCA’s own version of that, with a sad difference. Here, you don’t smash that button when something has gone wrong - smashing it is the only way for things to right, and for those changes you just made to go into effect.
Context Definitions
A context definition is how RCA lets you say, “Use this price, this rule, or this behavior… depending on who the customer is, where they are, when they’re buying, or how they’re buying”. Think of it like a data dictionary for RCA itself.
For example, if your Sales team sells out of CRM, RCA knows you’re using the Account object. But maybe customers also buy add-on licenses self-service, from within your own proprietary software, which has a different data model. You want your pricing logic to stay consistent, and you also only want to build and maintain a single pricing engine. To achieve this, you could customize Context Definitions to translate those multiple, varied data inputs into the same processing logic.
Decision Tables
Decision Tables are complex lookup tables that may come into play in various ways - pricing procedures, product disqualifications, etc.. For CPQ Admins, these are sort of like super-charged Lookup Queries you can use to apply complex business logic (e.g., based on how a product has been configured, auto-apply a specific % discount).
Qualification Rules
RCA provides myriad variations for how to control which products are available to be sold in a given context. Some of these scenarios are best met with the dedicated Qualification Rule framework - say, if premier services are only available for customers who’ve reached a certain spending threshold in the last 12 months. We just wanted to mention them - and not explore them in detail here - because we like to manage even scope toward MVP, even while blogging :).
And after all, even in Salesforce’s own admission, “Qualification rules can be a complex topic to understand.”
Product Setup
Companies have long been guilty of SKU proliferation, too often creating additional products in the system to meet reporting needs or support pricing changes - all at the expense of the user experience. This ultimately impeded sales productivity and confused customers (while ironically increasing reporting complexity).
Revenue Cloud’s data model separates “the product” from its pricing and packaging, allowing companies to maintain a simplified product catalog.
Product
Definition: You guessed it! This represents your Products.
CPQ Corollary: Products
Commentary: That was easy!
Example Use Case: A company sells their core software product.
Product Catalog Management
Definition: One-page app that centralizes the core objects used in RCA’s Product Setup.
CPQ Corollary: N/A
Commentary: Mild convenience for CPQ admins.
Example Use Case: Admin manages product setup using this app.
Structure
Definition: A Tab on the Product page, giving Admins an interface to create bundles and related Product configuration.
CPQ Corollary: N/A
Commentary: This UI helps admins visualize product structure and streamline data entry.
Example Use Case: Admin opens a Product record and configures/validates its components from this layout.
Cardinality
Definition: Cardinality is a feature underneath the Structure tab on the Product. It is also a concept in general, which refers to the idea that you can impose guardrails to ensure the right quantities - ”not too many, and not too few’ - get sold within a bundle.
CPQ Corollary: Fields on Product Options and Features.
Commentary: Leverage this concept to ensure your reps only configure bundles in acceptable ways.
Example Use Case: A car dealer requires you to choose which type of interior - cloth or leather.
Validate Product Definition
Definition: This is a capability offered to Admins within the Structure tab, giving immediate feedback as to whether they’ve configured a viable Bundle or there are issues with the structure of the Product.
CPQ Corollary: N/A
Commentary: Super helpful! Adopting this will accelerate product setup.
Example Use Case: Admin configures a product, and Validates Product Definition. RCA indicates there is a problem, which the Admin then troubleshoots. Admin reverifies, without issue.
Simple Products
Definition: A term you will find in Salesforce Help documentation, for Products that do not have a hierarchy (bundled). They may or may not be configurable.
CPQ Corollary: Products
Commentary: As if we needed more Salesforce jargon…
Example Use Case: A single a la carte item.
Static vs. Configurable
Definition: “Static” products are bundles that don’t allow sellers to configure them at all. You can probably therefore guess what Configurable means.
CPQ Corollary: Bundles
Commentary: This is more than just terminology, as RCA treats these differently and demands specific steps to convert a bundle from one to the other.
Example Use Case: Per Salesforce, (configurable) a “flatscreen TV that come in various sizes, all with standard remote control and sound bar.”
Product Selling Models (& Options)
Definition: An object used to specify the high-level behavior of products, as it relates to renewability and term. Each Product can be related to multiple Product Selling Models, via the Product Selling Model Option junction object.
CPQ Corollary: The Subscription Type and Subscription Term, etc. fields on the Product.
Commentary: This will help companies consolidate and standardize how their different products all “work,” while also significantly helping prevent SKU proliferation. Having a ton of these is probably a red flag.
Example Use Case: A mobile app offers both a monthly and an annual option. They only need one Product, but relate it to two different Product Selling Models.
Product Related Components
Definition: The individual components that make up the overall Bundle.
CPQ Corollary: Product Options
Commentary: N/A
Example Use Case: You sell software, and want to bundle that with 10 hours of technical support.
Product Component Group
Definition: Groupings of individual Product Components, helping to organize and control logic within a bundle.
CPQ Corollary: Features
Commentary: Heads up! Unlike CPQ Features, Component Groups are now REQUIRED for configurable bundles.
Example Use Case: You sell software, and want to bundle support with your licensing. You offer 3 tiers of support levels, all of which fall under your “Support Level” Product Component Group.
Bundle Based Adjustment
Definition: Discounts applied to a product, when that product is sold as a part of a bundle.
CPQ Corollary: Option-level Pricing
Commentary: N/A
Example Use Case: Premier Support costs $10k, but if the customer buys it bundled with software licenses, we can offer it for $8k.
Ramp Deals
Definition: A type of sales agreement where the price and volume of a product can vary across time periods. This is a framework for selling, and also a global setting that needs to be enabled to sell this way.
CPQ Corollary: MDQ (Multi-Dimensional Quoting)
Commentary: You may want to sell this way to secure longer contracts and uplift future pricing, but you should be aware there are challenging impacts on revenue recognition downstream. If you’re already selling this way, though, definitely use this.
Example Use Case: My subscription renews annually, but I want my customer to commit to a 3 year term. Pricing changes over time: $10k in year 1, $12k in year 2, $16k in year 3.
Product Ramp Segments
Definition: This is an object configured on an individual product, representing a specific configuration of a ramped deal.
CPQ Corollary: Price Dimensions
Commentary: You can associate these with only simple products (and NOT at the parent-level of bundles).
Example Use Case: I want to offer a month-long free trial.
Attributes
In Revenue Cloud Advanced, “Attributes” are how you describe a product beyond its name and SKU — things like color, size, tier, deployment region, flavor, etc.. They're structured data that drive configuration, pricing, rules, and even orchestration.
Unlike Salesforce CPQ, where configuration attributes are basically fields duct-taped to quote lines and often recreated per product, RCA treats Attributes like reusable building blocks: centrally defined, assignable across products, organized in tidy categories, and even inheritable from template-esque specification types. You can even decide if they matter to pricing. In this way, RCA’s attribute model is far more scalable and dynamic than CPQ’s - cleanly separated from quote line data in a way that increasingly supports modern pricing logic.
For example: A car company sells different types of vehicles, but all of them require the buyer to pick options for Color, Tires and Interior. In CPQ, these Configuration Attributes would need to be created manually for each product, and then maintained over time (“woops, buyers should pick Manual vs. Automatic too!”). This is time consuming and error prone. Instead with RCA, you now can create a global “Vehicle Features” Product Classification, and assign that to all your relevant Products - and in doing so, assign the same templatized Inherited Attributes for each SKU. Pretty nice!
But before you get too excited… are you also excited to hear that 8 of the 9 objects we define below all have names that include the word “Attribute”???
And you’re saying this relationship diagram doesn’t clear things up???
Attribute Definitions
Definition: The platonic ideal and template for an individual characteristic of a product. “Color,” for example, is an Attribute Definition that might apply to many of your products.
CPQ Corollary: Configuration Attributes
Commentary: If you have many products that share the same attributes (e.g., “Color”), this all has become easier.
Example Use Case: A car dealer sells different types of vehicles, all of which require the buyer to pick from among the same “Exterior Color” options.
Attribute Picklists
Definition: The container for values that are available for a given Attribute Definition. Abstract, we know.
CPQ Corollary: Configuration Attributes
Commentary: Hooray for a modular object model!
Example Use Case: A door manufacturer needs to specify both the Interior and also the Exterior Color of the door, which could differ. “Interior Color” and “Exterior Color” would be separate Attribute Definitions, but could be tied to the same Attribute Picklist because they have the same actual options to select.
Attribute Categories
Definition: Groupings of Attribute Definitions.
CPQ Corollary: N/A
Commentary: These can help improve the user experience of configuring a product.
Example Use Case: A car dealer wants to group all “Exterior Options” together.
Attribute Picklist Values
Definition: The options available within an Attribute Picklist.
CPQ Corollary: Picklist Values
Commentary: N/A
Example Use Case: In the Color example, these would be “Red” and “Blue.”
Product Classifications
Definition: Template for a Product’s multiple attributes, specified for a Product via the Based On lookup field.
CPQ Corollary: None
Commentary: This allows you to reuse logic across multiple products. If 10 of your products in CPQ worked the same way, you would have to rebuild all the child CPQ data manually, which takes time. This streamlines that process of both creation and then also of maintenance.
Example Use Case: A car dealer sells different types of vehicles, all of which require the buyer to pick options for Color, Tires and Interior. “Vehicle Features” is your Product Classification, which you can then assign to your Coupe, Sedan, SUV and Van products.
Inherited Attributes
Definition: Attributes inherited by a product based on the related Product Classification.
CPQ Corollary: N/A
Commentary: N/A
Example Use Case: A car dealer creates a new product to launch its new car model. It uses the pre-existing “Vehicle Features” product classification to assign Color, Tires & Interior as Inherited Attributes.
Overridden Inherited Attributes
Definition: Product/bundle-specific inherited attributes whose default values or behavior have been customized specifically for that product, overriding what was defined in the Product Classification
CPQ Corollary: N/A
Commentary: This allows for greater reusability of components while accommodating flexibility. Reuse a product classification on a product but override certain attribute values so that attributes are tailored to a product without recreating new attributes
Example Use Case: A car dealer creates a new product to launch its new car model. It uses the pre-existing “Vehicle Features” product classification to assign Color, Tires & Interior as Inherited Attributes. They add an additional “Sunroof” option to the new car, which is not available for other models.
Product Attribute Definitions
Definition: Attributes don’t need to come from Product Classifications. You can also assign them directly to Products, which are what this junction object represents.
CPQ Corollary: Configuration Attributes
Commentary: N/A
Example Use Case: You sell 100 products, but only one of them needs you to specify “Color.” Creating a Product Classification Type is overkill, so you just assign the “Color” Attribute Definition directly to the given Product.
Overridden Product Component Attributes
Definition: This is what happens when a product bundle (or parent product) includes child components that would normally inherit attribute values — but you intentionally give those components different attribute values in the context of that specific bundle.
CPQ Corollary: N/A
Commentary: Avoids proliferation of near-identical products just to reflect config changes in bundles, helping to keep the catalog clean.
Example Use Case: A company offers a product that, when sold standalone, has silver, gold, and platinum Tier options. However, when that product is sold as part of a bundle, it only allows gold and platinum to be selected.
Catalogs and Configuration
Salesforce has rebuilt the product configuration experience on Flow, which means it’s now significantly more flexible and powerful - and also potentially your problem. You can create beautifully dynamic, conditionally branching, attribute-driven guided selling Flows. You can also spend three months building logic to prevent a sales rep from bundling the wrong version of something no customer has ever actually bought.
Compared to CPQ, where configuration was rigid across all scenarios, RCA gives you a modern toolkit for advanced configuration. Whether you should actually use it, though - that’s a business maturity question, not a Salesforce one. We would argue that a lot of times, companies would be best served simplifying their product strategy, rather than engineering increasingly clever ways to enforce it.
Catalogs
Definition: Per Salesforce, “Catalogs enable efficient organization and management of all the products your business sells.” Basically, a specific list of Products that your company sells.
CPQ Corollary: Some combination of Pricebooks + Filtered “Product Search” Custom Actions
Commentary: This is a cleaner way of controlling which subset of your overall portfolio is available for purchase/sale.
Example Use Case: A software company has one “Inside Sales” Catalog containing all its available products, but a separate “Reseller” Catalog that offers a more limited selection to its network of Distributors.
Catalog Categories
Definition: These organize the products in a catalog into groupings and subgroupings.
CPQ Corollary: “Group By” CPQ Setting + picklist field on Product
Commentary: Adopting these improves the product selection experience during the quoting process.
Example Use Case: A technology company uses creates three Categories for its catalog: Hardware, Software and Services.
Product Configurator
Definition: Per Trailhead, the “Product Configurator is a Revenue Cloud application that simplifies product configurations, saving time and effort. Just select the desired options and attributes for a product, and the app automatically tailors the product specifications.”
CPQ Corollary: The Configurator
Commentary: This is an updated and more customizable UI that a seller/buyer can use to configure products.
Example Use Case: A Rep wants to edit bundle options via the product configurator while initially choosing their products, or after the fact.
Instant Pricing
Definition: Instant Pricing is a setting “where prices are re-calculated immediately on every configuration or line item edit within a quote or order. “
CPQ Corollary: “Calculate” button in the QLE, or enabling the ‘calculate immediately’ setting in CPQ settings.
Commentary: Turning this on is probably the right approach, unless you’re experiencing performance slowdown due to quote/configuration/pricing complexity.
Example Use Case: The configuration of a bundle dictates its pricing, and reps want to see that pricing impact happening in real-time.
Product Configuration Rules
Definition: These rules implement logic that lets you ensure products are configured correctly in complex scenarios.
CPQ Corollary: Product Rules
Commentary: These must be enabled in Revenue Settings.
Example Use Case: Per Salesforce: “If the user selects a laptop of brand A as part of a laptop bundle, then the docking station must be brand X, and the headphones must be brand Y. If the bundled product doesn’t meet these criteria, then the user sees a validation error message.”
Rule Libraries
Definition: A container or grouping mechanism for various Rules, including Configuration Rules
CPQ Corollary: N/A
Commentary: Yet another example of RCA’s modular and “global” philosophy.
Example Use Case: All Product Configuration Rules must be added to a Rule Library, but in some cases a company may want to create multiple Rule Libraries (e.g., “core” rules vs. “channel-specific” rules, with each library being owned and governed by Sales Ops and Channel Ops, respectively.
Product Configuration Flow
Definition: This is a new type of actual (screen) Flow that you are now able to build with RCA, which controls the experience of configuring products when adding to them in the quote.
CPQ Corollary: Product Fields (e.g., Configuration Type)
Commentary: RCA comes with a default Flow already created, but you are able to create custom ones (but please keep it simple!).
Example Use Case: Your reseller network builds quotes through a Partner Portal, and you want to create a streamlined and branded quoting experience for that audience.
Product Configuration Flow Assignment
Definition: Overrides the default Product Configuration Flow for individual products.
CPQ Corollary: N/A
Commentary: Since you can only assign one Flow to each Product, this could have been a lookup field rather that a junction - but at this point, what’s one more object?
Example Use Case: A company wants a specific product configuration flow for their new products to help users understand them better.
Example MVP Scope
Now that we’ve defined some concepts bottoms-up, let’s put it all together from a different angle to show how we can leverage these new capabilities where it makes sense while also still trying to keep it simple.
Scenario
AcmeSecure is a B2B cybersecurity company selling a mix of software subscriptions, services (both one-time and annually recurring), and physical hardware. Their go-to-market spans direct sales, partners, and customer success teams. As they scale, AcmeSecure wants to improve how they package and sell solutions, reduce reliance on custom SKUs, and ensure consistent logic across teams and regions.
They have ambitions in the future for product-led growth, sophisticated order fulfillment and a Salesforce-native billing process. But that said, they recognize they shouldn’t bite off more than they can chew, so they want to focus their initial RCA launch on only what truly needs to happen. This even applies to their distribution - even though they sell through partners, they decide to prioritize an internal-only Go Live.
Scope
The project design could be expected to look something like this:
Initial Setup
Enable whatever makes sense in Revenue Settings and Salesforce Pricing. Also make sure to Sync Pricing Data, and then also brace yourself for doing so a ton through this process :)
Product Selling Models
Create a One-Time record, and also a Term-Defined one for 1 Year.
We like getting here early, before Products themselves, because it helps solidify and standardize the revenue lifecycles of your products. Adding the Product Selling Model Option related list to this page layout is helpful as well.
Products
Create your simple Products, adding them to the appropriate Pricebooks while you’re at it.
When designing what Products to create, keep in mind concepts we touched on already. Try to avoid SKU proliferation. Think in an abstract and modular way, separating the idea of the “product” from all the related aspects of it (e.g., fulfillment components, attributes, billing options, etc.”). Think, too, about how your company organizes its overall product taxonomy hierarchy (e.g., product categories, product family, product groups, etc.).’
Keep in mind good general hygiene. Define a consistent Product Name, SKU and Code convention. Populate Product Descriptions.
Product Selling Model Options
Assign every Product an appropriate Product Selling Model, likely via data load. This is a pre-req for Ramp Deals.
Product Ramp Segments
Assuming you’ve enabled Ramp Deals under Revenue Settings, add the Product Ramp Segments related list to the Product page. Identify all recurring products (we don’t commonly see ramps for one-time products), and create (likely via data load) a “Yearly” Product Ramp Segment record for each SKU (associating it with the “1 Year” Product Selling Model)..
Product Classifications
Most products will not need Product Classifications - or Attributes at all - but AcmeSecure has a common pattern within its “Networking” suite of Products. Pricing is based on either the number of Servers, or the number of Users, for a given sale. The technical setup also differs based on “Hardware Form Factor,” which is either Virtual or Physical.
Here, create and activate a “Networking” Product Classification record, and inject this record into the Product Classification ID (BasedOnID) for all your Networking Products.
Attribute Definitions
Create two new “Picklist” Attribute Definitions, for each of the “License Type” and “Hardware Form Factors” mentioned above. In doing so, create the corresponding “Text” Attribute Picklists and their child Attribute Picklist Value records. Confirm everything has been Activated.
Return to your “Networking” Product Classification and Assign these Attribute Definitions, via the related list. These will now appear as Inherited Attributes on all your Networking Products!
Bundle Parent Products
The fact that AcmeSecure sells ramped deals will - just like it would in CPQ - force the company to create separate Products to serve as configurable Parents in bundles.
AcmeSecure offers an implementation bundle to enforce baseline product requirements, and also to help compel new customers to sign up. Create one new “Networking Implementation Bundle” product and add it to the Pricebook.
Structure & Cardinality
Use the Structure tab on the Bundle parent to create four Product Component Groups: Software, Hardware, and Services. Each of these Groups likely has a Min. Number of Components.
Add the relevant SKUs as Product Components within each Group. Some of these are likely required.
Catalogs
Create and maintain a single catalog, if you can get away with not needing multiple. Assign all active Products into this.
Create four child categories to group products intuitively by theme: Bundles, Software, Hardware, Services
Assign Products into the appropriate Catalog Categories.
Configuration
Prioritize keeping it simple, and adopt the out of the box Product Configuration flow. Reps might have ideas for UI improvement in UAT, but let’s ask them to adjust to the new format instead of agreeing to additional customization.
Put your faith in your team’s common sense, and don’t pre-emptively solve for edge case concerns. It’s true that the Networking Implementation Bundle from above should only be sold to new customers, but this is widely understood by the team. We therefore can exclude Qualification Rules, Rule Libraries and Configuration Rules from our scope.
And then now that you’re finally done with Products, it’s time to just quickly knock out Pricing!
…
Wait, you’re saying that won’t be quick?
….
Stay tuned for more on that front.
