You are here:
Pricing Architecture Changes
Pricing is one of the most architecturally significant differences between Salesforce CPQ and Revenue Management. If not explored early, it's one of the areas where complexity can emerge later. We recommend that the migration team develop a clear understanding of the pricing model changes, and its impact on configuration and migration before design decisions are finalized.
Pricing in CPQ
Pricing in Salesforce CPQ is built around a rules engine. Price rules evaluate conditions and apply adjustments in a defined sequential order. The order of execution matters, and changing the order changes the outcome.
Common CPQ pricing constructs include these components.
- Price rules are condition-based and sequentially run to calculate list price, net price, and special pricing.
- Discount schedules are volume-based and term-based discount tables applied to quote lines.
- Block pricing is tiered pricing that applies based on quantity ranges.
- Contracted prices are account-specific pricing overrides stored as CPQ custom records.
- Quote Calculation Plug-ins (QCPs) are custom code that the rules engine can’t handle natively. These plug-ins support margin guardrails, cross-line calculations, dynamic visibility, and any logic that the rules engine can’t express. While QCPs offer flexibility, they can become difficult to maintain over time when rules accumulate, dependencies between rules become hidden, and comprehensive documentation is lacking.
Pricing in Revenue Management
Revenue Management replaces the sequential rules engine with a structured pricing procedure model. A pricing procedure is a named, ordered sequence of pricing elements. Each element performs a specific pricing action such as applying a price book price, applying a discount, adding a surcharge, or calculating a margin floor.
- Pricing procedures offer greater flexibility and capability than CPQ price rulesets. They define the pricing calculation waterfall for a given context such as direct sales, partner channel, or ecommerce. They define the pricing calculation waterfall for a given context such as direct sales, partner channel, or ecommerce.
- Pricing elements are individual steps within a procedure. Each element has a type such as Manual Adjustment, Discount Schedule, Price List, Attribute-Based Pricing, and so on. See Use Pricing Elements in Pricing Procedures.
- Procedure plans define which pricing procedure applies based on context. These plans enable different pricing logic for each channel, customer segment, or product category without duplicating rules.
- Attribute-based pricing prices a product differently based on its configuration attributes without requiring separate SKUs or price rule conditions for each variant.
- Usage or consumption pricing is a native rating engine for consumption-based and tiered usage models. No custom code is required.
- Contracted item pricing provides account-specific or contract-specific price overrides by using standard Revenue Management objects, replacing ContractedPrices custom records of CPQ.
Pricing in Revenue Management is flexible and easier to maintain than the CPQ price waterfall. Here’s an example of a price waterfall for a quote line item in Revenue Management.
The net unit price of 10,260 is calculated by applying these discounts sequentially to the list price of 15,000.
| Step | Description | Calculation | Result |
|---|---|---|---|
| 1 | List price | None | 15,000 |
| 2 | Attribute-based discount | 15,000 − 3,000 |
12,000 |
| 3 | Bundle-based adjustment of 5% | 12,000 − (12,000 × 5%) = 12,00 − 600 |
11,400 |
| 4 | Volume discount of 10% | 11,400 − (11,400 × 10%) = 11,400 − 1,140 |
10,260 |
Redesign and Migration of Pricing Process
CPQ pricing logic rarely migrates without changes. The two systems define pricing in different ways. A direct rule-to-rule translation often produces incorrect results because CPQ rules depend on execution order, which has no direct equivalent in the pricing procedures of Revenue Management.
The move from CPQ's sequential rule engine to Revenue Management's pricing procedure model is therefore an opportunity to simplify your company's pricing process. The key question isn’t how to replicate existing CPQ rules, but what pricing outcomes the business actually needs and the clearest way to express them.
- Audit all active price rules and QCP logic before any migration work begins. Use AI-powered tooling, such as Forsys or IdeaHelix, to generate explainability reports on all CPQ price rules and QCP logic. Understand the intent and business purpose of each rule, whether it's list price, discount, margin protection, or channel adjustment, before attempting any redesign.
- Classify each CPQ rule into its Revenue Management equivalent. Straightforward price adjustments become pricing elements, and complex cross-line logic becomes custom Flows or Apex within the procedure.
- Rationalize pricing rules that have accumulated over time without clear ownership. Migration is the right moment to retire logic that is no longer commercially relevant.
- Map channel-specific pricing requirements for direct, partner, and self-serve channels to procedure plans in Revenue Management. This mapping enables a single product catalog with context-appropriate pricing rather than separate pricing constructs for each channel.
- If your business is moving towards hybrid monetization, configure consumption and usage-based pricing in Revenue Management. Rating procedures determine the final net rate for consumption by using specific rules and tiers that are defined in base, tier, or attribute rate cards.
- Validate the redesigned pricing against a curated quote pack, which is a representative set of historical quotes whose output prices are known. If the Revenue Management procedure produces the same results, the redesign is correct.
- For multi-currency orgs, migrate and validate one currency at a time to avoid rounding drift between price book entry values.
Before committing to a migration strategy, invest time in a pricing logic audit. The volume and complexity of your pricing customization is one of the strongest predictors of the overall migration effort.
Single Pricing Engine Across All Channels
Revenue Management's API-first architecture addresses the integration challenge of the proliferation of pricing logic across channels. Many companies end up maintaining separate pricing rules for direct sales, partner portals, and self-serve channels, creating three versions of the same truth that diverge over time and cause inconsistency for customers.
Every revenue operation in Revenue Management is exposed as an API. So, the same product, pricing, and configuration logic that powers the Salesforce UI can be consumed by a partner portal, a self-serve ecommerce experience, or an in-product purchasing flow without duplicating the rules. You can have a single catalog and a single pricing engine that works for every channel.
You can integrate third-party visualization tools, such as ThreeKit and RenderDraw, for visual product configuration.
