CPQ to Revenue Cloud Object and Feature Mapping: An Architect's Reference
Where every major Salesforce CPQ object goes in Revenue Cloud, what gets migrated as data, what gets rebuilt, and what has no direct equivalent.
The short answer: Salesforce CPQ stores everything in its own managed package objects (the SBQQ__ namespace). Revenue Cloud (marketed for a time as Agentforce Revenue Management) uses standard Salesforce objects instead. Quotes move to the standard Quote and Quote Line Item, bundles move to product component groups and related components, price rules become pricing procedures, discount schedules become price adjustment schedules, and subscriptions become managed assets. Some CPQ features, like the Quote Calculator Plugin and twin fields, have no direct equivalent and need to be redesigned.
In this guide
When CPQ owners start planning a move, the first technical question is always the same: "Where does all our stuff go?" Most migration guides stay at a high level. This one goes object by object, the way we map it in a real assessment.
A quick note before the tables: Revenue Cloud is changing fast, with new features in every release. Use this as a planning reference, and always confirm the details against your org and the current release notes before you design anything.
The big shift: from a managed package to the core platform
Three changes shape almost everything in the mapping below:
- Standard objects instead of SBQQ objects. Anything in your org that references an
SBQQ__object or field (Apex, flows, reports, integrations) will need to change. - Pricing runs on pricing procedures. CPQ's price rules, conditions and actions don't carry over. Pricing logic is rebuilt as a sequence of steps in a pricing procedure.
- Context definitions replace twin fields. In CPQ, you kept data in sync between quote lines, order products and subscriptions by giving fields the same API name. Revenue Cloud uses context definitions to decide which data is available to pricing and configuration, and how it maps between objects.
Product catalog and bundles
| Salesforce CPQ | Revenue Cloud | Notes |
|---|---|---|
Product (Product2) with CPQ fields | Product (Product2) | The object stays, but the CPQ package fields on it don't. Product behaviour moves to selling models, classifications and attributes. |
| Subscription fields on Product (subscription type, term, pricing) | Product selling models and selling model options | Defines whether a product is one-time, term-defined or evergreen, and the term length. One product can have several selling models. |
Product Feature (SBQQ__ProductFeature__c) | Product component group | Groups the options inside a bundle, with min and max rules. |
Product Option (SBQQ__ProductOption__c) | Product related component | Links a child product to a bundle. Quantities and required or default settings live here. |
| Configuration attributes | Product attributes and classifications | Attributes are defined once and reused across products through classifications, rather than per bundle. |
Product Rule, Error Condition, Product Action (SBQQ__ProductRule__c) | Configuration rules in the product configurator | Validation, selection and filter rules are rebuilt. The rule model is different, so this is a redesign, not a field mapping. |
Architect's tip: the catalog is where cleanup pays off most. If you have bundles with dozens of options that nobody selects, or near-duplicate products created for pricing workarounds, fix that before mapping. Every product you carry over adds selling models, pricebook entries and test cases.
Pricing and discounts
| Salesforce CPQ | Revenue Cloud | Notes |
|---|---|---|
| Price Book Entry | Price Book Entry, linked to a product selling model | The same product can have different prices for different selling models (for example one-time vs annual). |
Price Rule, Price Condition, Price Action (SBQQ__PriceRule__c) | Pricing procedure steps | The biggest rebuild in most orgs. Group your rules by what they actually do before redesigning them as procedure steps. |
| Lookup tables used by price rules | Decision tables | Lookup-style pricing (by region, segment, tier) is handled through decision tables referenced from pricing procedures. |
Discount Schedule and Discount Tier (SBQQ__DiscountSchedule__c) | Price adjustment schedule and tiers | Covers volume tiers and term-based discounts. |
| Summary variables | Aggregation within pricing procedures | Totals and counts across lines are calculated inside the procedure instead of in separate records. |
| Twin fields | Context definitions and mappings | See "The big shift" above. Plan this early, because custom fields that relied on twin field sync need a new home. |
Architect's tip: before rebuilding any price rule, check when it last fired. In most CPQ orgs we audit, a meaningful share of rules exist for promotions, products or edge cases that no longer apply. Our CPQ end of sale guide has a query to count your active rules.
Quotes, documents and approvals
| Salesforce CPQ | Revenue Cloud | Notes |
|---|---|---|
Quote (SBQQ__Quote__c) | Quote (standard) | Custom fields, page layouts, validation rules and automation on the CPQ quote all need to be recreated on the standard object. |
Quote Line (SBQQ__QuoteLine__c) | Quote Line Item (standard) | Bundle structure is kept through relationships between line items rather than CPQ's required-by fields. |
| Quote Template, Template Section, Template Content | Document generation templates | Quote PDFs are rebuilt from scratch. Collect your current templates and agree on what the new ones must show before you start. |
Advanced Approvals (sbaa__ package) | Approvals in Revenue Cloud (flow-based) | Approval chains, rules and conditions are rebuilt. A good time to simplify discount approval thresholds. |
Want this mapping done for your actual org, with every rule, field and integration listed? That's what our fixed-price readiness assessment delivers.
See how the assessment worksOrders, contracts and subscriptions
| Salesforce CPQ | Revenue Cloud | Notes |
|---|---|---|
| Order and Order Product with CPQ fields | Order and Order Product (standard), with order orchestration | Revenue Cloud adds fields and relationships CPQ orders don't have. Any integration that reads order data needs remapping. |
| Contract with CPQ fields | Contract (standard) | Contracts remain, but the way they connect to what the customer owns changes. |
Subscription (SBQQ__Subscription__c) | Managed assets (Asset with asset state periods and action history) | Instead of a list of subscription records, Revenue Cloud tracks each asset's state over time. This is the most important data transformation in the project. |
| Amendments and renewals (amend and renew from contract) | Asset-based amendments, renewals and cancellations | Changes are made against the customer's assets. Test co-terming and mid-term changes carefully with real contracts. |
Architect's tip: install base migration (moving active subscriptions to assets) is where projects slip. Pick five of your messiest real contracts, including ones with mid-term upgrades and co-terming, and use them as test cases from day one.
What has no direct equivalent
These are the items that need a design decision rather than a mapping:
- Quote Calculator Plugin (QCP). Custom JavaScript inside CPQ pricing has no direct home in Revenue Cloud. The logic has to be broken down and rebuilt in pricing procedures, decision tables, or custom Apex where really needed.
- Twin fields. Replaced by context definitions, which work differently. Every custom field that depended on twin field sync needs a decision.
- Complex price rule chains. Rules that depend on other rules, evaluation order tricks and workarounds usually need to be redesigned as a cleaner pricing procedure.
- Custom code on SBQQ objects. Apex triggers, flows and LWCs written against CPQ objects won't work. Each one is either rewritten, replaced by standard behaviour, or retired.
- Packages that extend CPQ. AppExchange apps built on CPQ objects need to be checked for Revenue Cloud support, or replaced.
What you migrate vs what you rebuild
A simple way to think about scope: data gets migrated, logic gets rebuilt. When Salesforce's migration assistant arrives, it may speed up parts of the left column and give you a starting point for the right one, but it won't make the design decisions for you.
| Migrated as data | Rebuilt as configuration or code |
|---|---|
| Products and pricebook entries | Selling models, attributes and classifications |
| Bundle structure (features and options) | Configuration rules |
| Discount tiers | Pricing procedures and decision tables |
| Active subscriptions (transformed into assets) | Amendment and renewal processes |
| Open quotes, if needed | Quote templates and approvals |
| Historical quotes and orders, if needed | Apex, flows, LWCs and integrations |
On historical quotes: you don't always need to migrate years of closed quotes into the new model. Many teams keep them read-only in the old objects for reference and reporting, and only move open quotes and active contracts. Decide this early, because it can change the size of the data work a lot.
Common questions
What replaces SBQQ__Quote__c in Revenue Cloud?
The standard Salesforce Quote object. Quote lines move to the standard Quote Line Item object.
Do CPQ price rules work in Revenue Cloud?
No. Price rules, conditions and actions are not supported. Pricing logic is rebuilt using pricing procedures, often with decision tables for lookup-style pricing.
What happens to CPQ subscriptions in Revenue Cloud?
They become managed assets. Revenue Cloud tracks the state of each asset over time, and amendments, renewals and cancellations are made against those assets.
Is there a Revenue Cloud equivalent of the Quote Calculator Plugin?
Not directly. QCP logic has to be redesigned using pricing procedures, decision tables, or custom Apex where it's really needed.
Can CPQ data be migrated to Revenue Cloud automatically?
Not fully, today. Salesforce has a CPQ migration assistant on its roadmap for December 2026, covering configuration as well as data. Even then, anything that works differently in Revenue Cloud, like price rules, QCP, twin fields and renewals, still needs redesign and testing.
Get this mapping for your own org
Book a 30-minute CPQ review with our architect. We'll look at your setup and show you where the real work is before you commit to anything.
Book your CPQ review