In 2026, the transition to Agentforce Revenue Management (formerly Salesforce Revenue Cloud) is firmly underway. With Salesforce CPQ (legacy Steelbrick) officially reaching ‘end of sale,’ organizations are evaluating their future.
But for IT and RevOps leaders, the question isn’t just about moving to the next version, it is about whether a complete migration to a new platform is the best use of enterprise resources.
Is It Time for a New Approach to Revenue?
Traditionally, sales and RevOps teams have relied on products like Salesforce CPQ to manage deal costs, terms, and pricing models.
But, by definition, CPQ has little to offer after sales teams have closed the deal. For ongoing billing, contract changes, invoicing, and reporting, organizations have to look elsewhere. In practice, this means that many handle pre-sales tasks in their CPQ, and everything for post-sales elsewhere (e.g. a specialist billing solution, ERP, etc.). This siloed approach creates several issues:
- Manual reconciliation: Siloed CPQ and billing systems generally rely on separate data models. While these can be aligned through integration, getting it right is technically exhaustive. If these connections are poorly built, RevOps teams are forced to manually bridge the gap between platforms – a labor-intensive process prone to human error.
- Conflicting pricing logic: Different platforms run on separate product catalogs and pricing logics. By default, these will conflict, again requiring complex manual integrations or manual reconciliation
- Changes create more conflict: Often, contract amendments are defined in the CPQ, but aren’t represented accurately elsewhere. This is a particular issue if only one or neither of the systems supports your contractual requirements. In this case, employees are often forced to guess the answer to questions like ‘does this replace the old schedule?’, ‘should it run in parallel?’, or ‘how will the prorated amount be calculated?’
- Contracts don’t reflect reality: Often, organizations will rely on CRM/CPQ automations or have to write Apex logic to generate automated renewal opportunities or quotes. If mid-contract changes aren’t synced back to CPQ from billing platforms, the system will likely generate renewal quotes based on the original contract, rather than the current reality. Then, revenue teams have to manually correct these mistakes.
- Inaccurate data: To project revenue, finance teams need accurate data on ongoing subscriptions and annual recurring revenue (ARR). With outdated, conflicting, or incorrect data, this is impossible to achieve.
This problem is only getting more challenging because organizations are increasingly adopting more complex pricing models. Often, these mix established seat-based pricing with more complex consumption-based approaches, which only amplifies the confusion and disconnect.
Clearly, it’s time for a better approach. But what does that look like? And is Agentforce Revenue Management the best option?
The Four Principles of Unified Revenue Operations
The best way to solve this problem is to bring pre-sales, revenue management, and ongoing billing functionality into the same unified product. To Salesforce’s credit, this is the driving force behind its shift from Salesforce CPQ to Revenue Management. Though of course, the devil is in the details…
To solve this, a modern revenue stack requires four distinct architectural layers working in sync:
- Governance: First, you need a single product catalog that encompasses quoting, subscriptions, and billing. Pricing, discounting, and approval logic should be defined in the CPQ and consistently enforced through the whole range of post-sales revenue functions.
- Lifecycle: This involves a single data pipeline to manage all of a customer’s revenue interactions, including initial deal, subscription terms, billing events, invoices, and revenue schedules. Mid-cycle changes (like term changes, ramp schedules, or subscription expansion) should automatically flow from the CPQ into subscriptions and billing dashboards.
- Data model: CPQ, billing, and subscriptions functionality should all operate from a single shared data model that covers both recurring revenue (annual and monthly), invoicing, and payment schedules. This eliminates conflicting records and the need for manual data reconciliation.
- Operational: Naturally, the solution also needs to include all the day-to-day functionality that employees already rely on. That includes audit-ready billing and invoicing (for finance teams), pricing logic and rules (for RevOps), and quoting/deal management (sales).
These are essentially the four key principles of unified RevOps. Done right, the model ensures CPQ and billing can operate as one system, creating a predictable, governable, and scalable revenue stack.
How to Achieve Unified RevOps: Pros and Cons of the Main Options
But here’s the key question: How do you actually create this unified RevOps platform? And how do you ensure it works seamlessly with your existing Salesforce CRM?
Here, there are essentially three options, each with its own pros and cons:
1. Agentforce Revenue Management
Revenue Management is the successor to Salesforce CPQ, explicitly combining quoting, billing, and revenue management. While the vision of a unified product is a clear evolution, it’s important to be aware that moving to Revenue Management is not a straightforward migration. In fact, it’s a full-scale re-implementation.
This is because the underlying data model is fundamentally different from Salesforce CPQ. You aren’t just clicking ‘upgrade’ – you’re embarking on a fundamental re-architecting of your entire quote-to-cash flow. And that’s just to get back the functionality you already have today.
For IT architects, the complexity of this transition lies in three incompatible architectural layers:
| Layer | Legacy Salesforce CPQ | Agentforce Revenue Management (ARM) |
|---|---|---|
| Pricing Engine | JavaScript-based (QCP) running in-browser | Server-side Pricing Procedures: QCP scripts cannot be ported. |
| Product Catalog | Standard Product/Pricebook objects | New PCM (Product Catalog Management) – Incompatible with legacy objects. |
| UI Layer | Packaged Quote Line Editor (QLE) | OmniStudio + LWC – requires bespoke rebuild. |
2. Third-Party Software
There is also a range of third-party software products on the market that can help. Generally, these will be SaaS-based RevOps platforms that are either built on Salesforce or integrate with it.
The benefit of this approach is that you can be highly specific about the functionality you choose, since you can choose the vendor that best matches your needs. They also come with fewer overheads and faster implementation cycles than Agentforce Revenue Management or custom builds.
Nonetheless, there is significant variation in the breadth of functionality on offer and how effectively they unify different revenue functions. It’s important to ensure any solution satisfies the architectural principles we discussed above.
3. Custom Platform
The other option here should be approached with some caution: Building custom integrations and data pipelines. This is best-suited to larger organizations with skilled developer resources on hand.
This option could involve building your own internal business apps or simply creating custom integrations between existing solutions like Revenue Management.
These options give you the most control over the ultimate platform you end up with, how it stores and reconciles data, and how users will interact with it. But it’s also fraught with risk, requiring significant up-front investment to create and maintain, and requiring more developer time for future updates. Done badly, it also risks simply replicating the issues we described above.
DealHub: The Revenue Execution Layer for the Salesforce Ecosystem
DealHub provides a specialized execution layer that sits natively on Salesforce, allowing IT to offload complex business logic without losing architectural control. Unlike a full-scale Revenue Management re-implementation, DealHub is additive: it keeps your CRM as the system of record while governing the transaction logic in a dedicated engine.
Here is how DealHub’s architecture helps you to build an effective and unified revenue stack:
- Logic Ownership (Governance): DealHub’s operator-owned configuration engine transfers the maintenance of pricing rules and approval thresholds from IT to RevOps. This is “No-Code” that doesn’t sacrifice visibility – IT maintains full audit trails and version control, but the daily “support ticket” burden for GTM changes is eliminated.
- Lifecycle Continuity: DealHub maintains a single data pipeline for the entire customer journey. Whether it’s an initial quote, a mid-term amendment, or a complex renewal, the system ensures the commercial intent remains tied to the contract. No more manual “swivel-chair” data entry between CPQ and Billing.
- Clean Data Schemas: Quoting, billing, and subscription data operate from a single, relational data model. This ensures that every transaction is captured as structured context – not just raw event logs. The result is data that is “warehouse-ready” for Snowflake or Tableau, requiring no complex ETL to reconstruct the revenue story.
- Deterministic Execution: While Sales teams operate within the DealHub interface they love, the system enforces your organizational policies with zero latency. Pricing strategy decided in the boardroom is encoded into the field execution, ensuring that what was approved is exactly what gets billed.
- The Technical Advantage: For the Salesforce Architect, DealHub offers a leaner, faster org. It supports the most complex pricing models, including multi-year ramps, consumption-based pricing, and co-termed expansions, without requiring custom Apex triggers or Flow workarounds.
There are many ways to unify your revenue operations. But DealHub is the only one that combines fast implementation and time-to-value with a “Clean CRM as system-of-record” architecture.
Explore the platform or book a demo to find out more.
