Let’s first understand the erstwhile Salesforce CPQ

Before diving deep into Revenue Cloud lets just understand its former Salesforce Offering the Salesforce CPQ which came from the Steel bricks. Salesforce initially added it to its Service Cloud offering. Salesforce CPQ was built entirely on the Force.com platform as a managed package. Its architecture balances declarative configuration (managed package metadata) with programmatic extensibility via the CPQ Quote Editor and Advanced Quote Calculator (AQC). The managed package brought in custom objects, logic, and UI components that would sit on top of the CRM data.

The CPQ integrated with the standard objects – Account, Opportunities, and Users. Then the custom entities included – Products, Price books, Quote, Quote Line, Product Options & Features.

Because it is a managed package, the core code is obfuscated and locked. Customizations must use supported extension points (like Plugins or APIs) so that upgrades do not break local logic.

Calculation Engine & The Advanced Quote Calculator (AQC)Salesforce CPQ

This relies on a decoupled, JavaScript-based calculation engine known as the Advanced Quote Calculator (AQC).

• Decoupled Processing: Calculations do not run directly on the standard Apex database transaction engine. Instead, data is serialized and sent to a secure, external Heroku-based service running Node.js.

• Asynchronous & Synchronous Execution: Calculations run asynchronously during complex UI interactions to prevent browser freezing, but save actions commit synchronously to Salesforce objects.

• Pricing Lifecycle: The AQC executes a multi-step sequence:

  • Initialize: Load quote and line metadata.

  • Apply Formula & Target Pricing: Evaluate initial quantities and static discounts.

  • Price Rules (On Initialization): Inject values based on foundational rules.

Programmatic Extensibility: The CPQ API

The Salesforce CPQ API allows developers to bypass the standard Quote Line Editor (QLE) user interface to read, manipulate, and save quotes programmatically. This is crucial for B2B e-commerce integrations, external portals, or custom mobile apps.

The API architecture exposes four primary service models through Apex:

• Product API

  • Purpose: Loads product data, handles validation, and determines configuration options for a user session.

  • Key Class: SBQQ.ServiceRouter.load('SBQQ.ProductAPI.ProductLoader', ...)

  • Utility: Validates if a bundle structure is correct before adding it to a cart.

• Configurator API

  • Purpose: Validates product configurations and processes product rules.

  • Key Class: SBQQ.ServiceRouter.load('SBQQ.ConfiguratorAPI.ConfigurationValidator', ...)

  • Utility: Evaluates if selected options violate constraints (e.g., Option A requires Option B).

• Quote API

  • Purpose: Reads, creates, updates, and saves CPQ Quote and Quote Line records.

  • Key Class: SBQQ.ServiceRouter.read('SBQQ.QuoteAPI.QuoteReader', ...) and SBQQ.QuoteAPI.QuoteSaver

  • Utility: Automates quote creation from external transactional inputs.

• Transaction Patterns (Models) The API relies heavily on tightly structured Apex Data Transfer Objects (DTOs) called Models.

  • QuoteModel: Contains the SBQQ__Quote__c record and a list of QuoteLineModel records.

  • State Management: Because CPQ uses an external calculation engine, you cannot simply update an SBQQ__QuoteLine__c record via standard DML and expect pricing to update. You must load the data into a QuoteModel, pass it to the Quote Calculator API, and then save the resulting model using the CPQ API tools to ensure all internal pricing scripts run.

  • Calculate System Discounts: Process block pricing, tier pricing, and term discounts.

  • Price Rules (On Calculate): Evaluate custom pricing logic.

  • Summary Totals: Roll up net amounts to the quote line and quote header.

Integration Hooks & Custom Logic Extensions

When standard Price Rules and Product Rules cannot meet business requirements, the architecture provides two managed hooks:

• Custom Scripting (QCP): The Quote Calculator Plugin (QCP) is a JavaScript file uploaded into Salesforce. The AQC executes this script directly within its Node.js environment during the calculation cycle, bypassing Apex governor limits for complex math.

• Apex Plugins: Interfaces like SBQQ.ProductSearchPlugin or SBQQ.DocumentStorePlugin allow Apex code to override default managed package behavior, such as altering how products are searched or where PDF quotes are saved.

Why Salesforce called End of Life for Salesforce CPQ?

We all who have used Salesforce CPQ know it is great tool at the sales stage for configuring, pricing and quoting. Any Sales Leader or sales user would know the hassles after that; the entire billing lifecycle would start with either or majorly integration with a third-party ERP billing system. Now that means a huge shift from the traditional native salesforce experience to another third-part experience, which sometimes was superb or at times would be miserable or just hanging there. Now not that salesforce did not have any offering for the billing. It did offer the Salesforce Billing as a managed package. But it never became the front-face offering of Salesforce as a Billing solution. Rather it provided a solution for Order or Contract for financial execution. It would start after a deal was closed and then started from order and converted them to Invoices, processed payments, calculate taxes, and tracked revenue recognition.

Anyone who used Salesforce Billing would face problems like:

• It was provided as another managed package so there was an additional overhead of data flowing between the CPQ package to the billing package and involved handling of the calculations separately causing issues in mismatch of pennies. Also, this meant data synchronization between objects relied on heavy automation logic that was prone to error.

• Large enterprises frequently hit Salesforce governor limits. For example, the system struggled or failed to post complex invoices containing thousands of line items in a single transaction.

• Making mid-term contract amendments, renewals, or asset-level modifications often trigger unexpected billing behaviors or broken calculation logic.

• Legacy Billing natively supported only basic flat-rate or simple recurring subscriptions. It lacked the native agility to handle sophisticated, modern monetization models like multi-tier overages, prepaid digital wallets, or rollover consumption

• Custom invoicing schedules outside standard monthly or annual terms required complex "Invoice Plans". These plans often broke if an order product was modified or amended downstream.