CPQ Specialist Interview Questions

The Salesforce CPQ data model extends standard CRM objects with a set of managed package objects (prefixed SBQQ__): (1) SBQQ__Quote__c: The CPQ quote, a child of Opportunity. Holds the price book, account, billing/shipping, quote validity, and quote-level discounts. (2) SBQQ__QuoteLine__c: Each product line on the quote. Stores quantity, list price, customer price, net price, discount, subscription fields, and parent bundle references. (3) SBQQ__Subscription__c: Created when a quote is contracted; tracks each subscription product's term, quantity, and pricing on the Contract. (4) SBQQ__Contract__c: An extension of the standard Contract object with CPQ-specific fields (subscription term, auto-renew flag, MDQ settings). (5) SBQQ__Order__c / OrderItem: CPQ generates standard Orders and Order Products from a contracted quote. The SBQQ package adds subscription references back to the order item. Understanding these relationships — Quote → QuoteLine → Subscription → Contract → Renewal Quote — is essential for tracing how a deal moves from configuration to revenue.

A Bundle is a parent product that contains child products called Options, grouped into Features (logical groupings displayed in the product configurator). Configuration: (1) Parent Bundle: A Product2 record with the "Component" or "Bundle" product type. (2) Features (SBQQ__Feature__c): Sections within the configurator (e.g., "Platform", "Add-ons", "Support"). Each feature has a minimum and maximum number of options that must be selected. (3) Options (SBQQ__Option__c): Join records linking a product to a bundle feature. Options can be marked as Required (always included, greyed out in configurator), Selected by Default (pre-checked but removable), or Optional (user selects). (4) Quantity: Option quantities can be fixed, user-entered, or matched to the parent's quantity. (5) Configured SKU: The parent bundle and all selected options appear as separate lines on the quote, with the parent as the primary line and options as components (hidden from the quote document or shown, configurable per template).

Option Constraints (SBQQ__OptionConstraint__c) define dependency rules between options within a bundle. They automate the relationship logic so that selecting one option affects the availability or selection of another. The two constraint types are: (1) Requires: If Option A is selected, Option B must also be selected. The configurator will either auto-select Option B or prevent saving until the user adds it, depending on the "Auto Select" flag. Use case: selecting a "Professional Services" add-on requires the "Base Platform" option to be included. (2) Excludes: If Option A is selected, Option B cannot be selected at the same time. Useful for mutually exclusive tiers — selecting "Enterprise Edition" excludes "Standard Edition". Option Constraints reference a "Constrained Option" (the option being affected) and a "Constraining Option" (the option that triggers the rule). This replaces manual configuration guidance with automated guardrails inside the configurator.

Product Rules (SBQQ__ProductRule__c) enforce configurator logic based on combinations of products or field values. The four types are: (1) Validation Rule: Prevents the user from saving the quote if conditions are not met. Displays an error message. Evaluated on save. Use case: block saving if a subscription product is added without a support option. (2) Alert Rule: Warns the user with a message but allows them to proceed. Evaluated on save or on change. Use case: notify a rep that a discount exceeds the standard threshold. (3) Selection Rule: Automatically adds, removes, hides, or disables options when conditions are met. Evaluated when a product is added or a quantity/field changes. Use case: auto-add a required connector product when a specific integration is selected. (4) Filter Rule: Filters the products shown in the add products search or catalog based on conditions. Evaluated when the product catalog is opened. Use case: show only products compatible with the selected edition. Each rule uses Product Conditions (what triggers the rule) and Product Actions (what happens).

The CPQ Pricing Waterfall is the sequential chain of calculations that derives the final price for each quote line. The stages are: (1) List Price: The price from the Price Book Entry — the starting point. (2) Regular Price: List price after any contracted pricing (block pricing or contracted price) is applied. (3) Customer Price: Regular price after Discount Schedules (volume/tier discounts based on quantity) are applied. (4) Partner Price: Customer price after Partner Discount (a field on the quote line, typically populated by a distributor markup/markdown). (5) Net Price: Partner price after Additional Discount — the final price the customer pays. Each stage can be influenced by Price Rules (which can target any price field in the waterfall). The Unit Price on the quote line reflects the net price per unit; the Net Total is unit net price × quantity. Understanding which waterfall stage a Price Rule targets is critical for correct pricing behaviour.

Discount Schedules (SBQQ__DiscountSchedule__c) apply automatic volume or tiered discounts to quote lines based on quantity or amount. Schedule types: (1) Slab: The discount for the highest applicable tier applies to the entire quantity. Example: 1–10 units = 0%, 11–50 units = 10%, 51+ units = 20%. If a rep quotes 60 units, the entire quantity gets 20% discount. (2) Range: Each tier's discount applies only to the quantity within that tier (like progressive tax brackets). For 60 units: the first 10 get 0%, next 40 get 10%, final 10 get 20%. The blended effective discount is lower than slab. Pricing method for discount schedules: (1) Additive: The discount is added on top of any existing manual discount on the line. (2) Exclusive: The schedule discount replaces any existing discount. Discount schedules are associated with products or price book entries and are evaluated as part of the Customer Price step in the pricing waterfall.

Price Rules (SBQQ__PriceRule__c) dynamically set field values on quote lines or the quote header based on conditions. Architecture: (1) Price Rule: The parent record defining when the rule fires — either on calculator (when the quote calculator runs) or on save. It has an evaluation scope (quote, quote line, or both) and an evaluation event (always, on add, or on calculate). (2) Price Conditions (SBQQ__PriceCondition__c): Child records of the Price Rule that define qualifying criteria. Each condition specifies a tested object (Quote, Quote Line, Summary Variable), a field, an operator, and a value. Multiple conditions can use AND/OR logic. (3) Price Actions (SBQQ__PriceAction__c): Child records that specify what happens when conditions are met — the target object (Quote or Quote Line), the target field, and the source (a formula, a field lookup, or a summary variable). Common use cases: set a special price on a quote line when a specific product combination is selected, populate a custom discount field based on a contract tier, or lock a price for a specific account segment.

The Quote Line Calculator is CPQ's internal pricing engine that computes the pricing waterfall values for all quote lines on a quote. It runs as an asynchronous process on the Salesforce server. Trigger events: (1) When a product is added to or removed from a quote. (2) When quantity, discount, or subscription term fields on a quote line are changed. (3) When the "Recalculate" button is clicked manually. (4) Via the CPQ Calculate API (for programmatic price refresh). (5) When a Price Rule with "On Calculator" evaluation event applies. Batch size: The calculator processes quote lines in batches. The default batch size is configurable in CPQ Package Settings (typically 2–5 lines per batch for complex quotes). Reducing batch size lowers the risk of hitting governor limits in large quotes but increases the number of callouts. For quotes with hundreds of lines, consider using the asynchronous CPQ API to offload calculation. Custom price calculations can hook into the calculator via Custom Price Methods (Apex classes implementing the SBQQ.PricingPlugin interface).

CPQ Package Settings (Setup > Installed Packages > Salesforce CPQ > Configure) contain critical configuration knobs: (1) Default Quote Validity (days): Sets the default expiration date on new quotes. (2) Price Book Selection: Determines how CPQ selects the price book for a quote — by account currency, by a custom field, or manually by the rep. (3) Order Settings: Enable "Order by Quote Line Group" to create separate orders per group; enable "Contracted Pricing" to lock net prices on contracts. (4) Quote Calculator Batch Size: Controls lines per calculation batch — tune for performance. (5) Subscription Proration Precision: Day or Month — affects how mid-term subscription prices are pro-rated. (6) Enable Large Quote Experience: Switches the quote configurator to a performance-optimised mode for quotes with many lines. (7) Default Subscription Term: Applied when no term is specified on the quote. (8) Auto-Create Contracts: Automatically creates a contract when an opportunity is marked Closed Won. Misconfiguring package settings is a common source of CPQ bugs — always test changes in a sandbox first.

Subscription products have SBQQ__SubscriptionType__c set on the Product record. The three types are: (1) Renewable: The product creates a Subscription record when contracted and is eligible for renewal quotes. Most SaaS products use this type. (2) Evergreen: Creates a Subscription record but is never included in renewal quotes — it continues indefinitely until manually cancelled. Suitable for metered or open-ended services. (3) One-Time: Does not create a Subscription record; it is treated as a one-time charge despite potentially being on a subscription quote. Subscription Term: Defined on the quote; the duration (in months) drives pro-rata pricing if the subscription term differs from the standard term. Pricing Method on the product: (a) Fixed Price: A flat price per subscription term regardless of quantity. (b) Per Unit: List price × quantity × (subscription term / 12) for annual normalisation. (c) Percent of Total: Price is a percentage of the total of other lines (e.g., a support contract priced at 20% of platform licenses).

An Amendment Quote is created to modify an active contract mid-term — adding, removing, or changing subscription quantities. Key characteristics: (1) Quote Type: Set to "Amendment" on the SBQQ__Quote__c record. (2) The amendment quote is triggered from the Contract record via the "Amend" button, which creates a new Opportunity and Quote. CPQ pre-populates the quote lines with the current contracted subscriptions. (3) Delta Quantity: The quantity on an amendment line represents the change (positive for additions, negative for removals) rather than the total quantity. CPQ calculates the net new ARR/MRR. (4) Delta MRR: The monthly recurring revenue change from the amendment — visible on the quote line and useful for reporting. (5) Co-termination: The amendment subscription term runs from the amendment effective date to the contract end date, ensuring all subscriptions renew together. Pro-ration is applied automatically based on the remaining term. (6) Contracted pricing from the original contract is preserved on amendment lines unless explicitly overridden.

A Renewal Quote is generated to re-sign a customer at the end of their contract term. Key behaviours: (1) Auto-Renewal: If the Contract's SBQQ__AutoRenew__c flag is true and a renewal forecast date is reached, CPQ automatically creates a Renewal Opportunity and Quote. (2) Renewal Pricing: Three options on the Contract or CPQ Package Settings: (a) Same: Retains the exact contracted net price. (b) Uplift: Applies a percentage price increase (configured at contract or product level — SBQQ__RenewalUplift__c). (c) List: Resets to the current price book list price. (3) Co-termination: All subscriptions on the contract share the same renewal date, even if amended mid-term. (4) Renewal Term: Defaults to the original contract term unless overridden on the Contract. (5) The Renewal Quote type is set to "Renewal", and renewal quote lines reference the originating Subscription records. Any add-on or upsell introduced during renewal follows standard quote configuration.

Twin Fields is a CPQ mechanism for mapping field values from a Quote Line (SBQQ__QuoteLine__c) to the corresponding Subscription record (SBQQ__Subscription__c) at contract creation, and optionally from Subscriptions to Renewal Quote Lines at renewal generation. Use case: If you have a custom field SBQQ__QuoteLine__c.Custom_Discount__c that stores a negotiated discount, you create a field with the exact same API name on SBQQ__Subscription__c. When the quote is contracted, CPQ automatically copies the value to the subscription. On renewal, CPQ copies the value back to the renewal quote line. This avoids the need for custom Apex or Flow to synchronise custom data through the quote-to-contract-to-renewal lifecycle. Twin Fields work for all data types. For fields that should map between Quote and Order Item, CPQ uses a similar mechanism driven by matching API names across SBQQ__QuoteLine__c and OrderItem.

CPQ introduces its own approval framework via the SBQQ__Approver__c object and SBQQ__ApprovalCondition__c objects, which complement (or replace) standard Salesforce Approval Processes for quotes. Key differences and features: (1) Approval Variables: Evaluate conditions across quote lines (e.g., "if any line has a discount > 30%") — standard approvals cannot easily aggregate line-level data. (2) Approver Object: Defines who approves and under what conditions; approvers can be users, roles, or groups. (3) Chain vs Parallel: Approvers within a step can be configured as sequential (chain — each approves in order) or parallel (all must approve simultaneously). (4) Quote Approval Status: The Quote's approval status field (SBQQ__ApprovalStatus__c) reflects the overall state (Pending, Approved, Rejected). Approvals can be triggered automatically when a quote is submitted or when the "Submit for Approval" button is clicked. CPQ also supports standard Salesforce approval processes layered on top of the CPQ approval object for simpler use cases.

CPQ Output Documents generate professional PDF or Word quotes from a Quote Template (SBQQ__QuoteTemplate__c). Structure: (1) Template Sections: Logical blocks of content — header, terms, line items table, signature. Sections can be conditional (shown/hidden based on quote field values). (2) Line Columns: Define which fields appear in the line items table and their labels. Columns can be formatted (currency, percentage, text) and conditionally shown (e.g., hide "Discount" column if no line has a discount). (3) Conditional Content: Rich text or HTML blocks that appear only when specific conditions are true (e.g., show "Enterprise SLA" section only if the Enterprise Support option is selected). (4) Grouping: Lines can be grouped by Quote Line Group for a cleaner document structure. (5) DocuSign Integration: The generated document can be sent directly to DocuSign from the quote via the "Send with DocuSign" button (requires DocuSign for Salesforce CPQ integration). The template is assigned to the Quote record type or selected by the rep, and the document is generated on-demand or automatically when the quote reaches a certain status.

The CPQ REST API (available at /services/apexrest/SBQQ/ServiceRouter) allows external systems and Apex code to interact with CPQ quote data without going through the UI. Key APIs: (1) Read API (reader=SBQQ.QuoteAPI.Reader): Returns a JSON representation of a quote including all quote lines, options, and pricing data. Used to read the current state of a quote programmatically — for integrations that need to send quote data to an ERP or CPQ reporting system. (2) Calculate API (saver=SBQQ.QuoteAPI.Saver): Takes a JSON quote payload, runs the CPQ pricing calculator, and saves the updated quote. Used when building custom configurators, integrations, or batch re-pricing jobs. The flow is: Read → modify the JSON → Calculate/Save. (3) Product Search API: Queries available products with pricing for a given quote context. Use cases: recalculating prices in bulk after a price book change, integrating with a third-party e-commerce or CPQ tool, and automating quote creation from an external system (e.g., a partner portal).

CPQ supports two JavaScript-based extension points for customisation: (1) Custom Price Methods (SBQQ.PricingPlugin): An Apex class implementing the SBQQ.PricingPlugin interface can override or supplement the standard calculator. The plugin receives the quote model as JSON, applies custom logic in Apex, and returns the modified model. While this is Apex (server-side), the plugin is invoked by the JavaScript-based CPQ calculator in the browser and can call back to Apex via the CPQ API. (2) Summary Variables can be used in Price Actions for aggregate calculations. (3) For UI-side customisation, CPQ supports Custom Script records (SBQQ__CustomScript__c) which allow JavaScript to run within the CPQ quote configurator page. These scripts can modify option visibility, field values, and UI behaviour in real-time — for example, displaying a custom warning based on a combination of selected options or auto-populating fields based on external data. Custom scripts require careful testing as they run in the browser's scope and can affect configurator performance.

When multi-currency is enabled in the Salesforce org, CPQ respects the currency settings across its objects: (1) Price Book Entries: Products must have a Price Book Entry for each active currency; CPQ selects the appropriate currency entry when the quote's currency is set. (2) Quote Currency: Set on the Quote record (CurrencyIsoCode). All quote line prices are displayed and stored in the quote currency. (3) Corporate Currency Conversion: The Quote's Total Net Price is stored in the corporate currency for reporting and forecasting. (4) Advanced Currency Management (Dated Exchange Rates): If enabled, CPQ uses the exchange rate effective on the Quote's Effective Date (or Close Date) for currency conversion — important for accurate historical revenue reporting. (5) Multi-Currency with Subscriptions: Subscription records inherit the contract's currency; amendment and renewal quotes retain the currency of the original. Note: changing the currency on an in-progress quote recalculates all prices — CPQ does not retain the original currency prices after a currency change.

CPQ access is controlled by licence assignments and permission sets: (1) Salesforce CPQ User Licence: Required for any user who creates or edits quotes, configures products, or manages the CPQ back-end. Assigned via the CPQ Permission Set Licence in Setup. (2) Salesforce CPQ Admin Licence: Required for users who configure CPQ objects (price rules, product rules, discount schedules, templates). Includes all User Licence permissions plus admin capabilities. (3) Permission Sets: CPQ installs several permission sets — SBQQ CPQ User grants access to CPQ quote objects; SBQQ Admin grants full access including setup objects. Users must be assigned the correct permission set in addition to the licence. (4) API-Only Users: Integration users making CPQ API calls require a CPQ licence. (5) Profile/FLS: Even with CPQ licences, FLS on CPQ fields must be open for the user's profile or permission set. A common issue is a user having the licence but missing FLS — resulting in blank or read-only CPQ fields.

Large quotes (50+ lines) can cause performance issues in CPQ. Key strategies: (1) Batch Calculation Size: Reduce the calculator batch size in CPQ Package Settings to process fewer lines per batch — avoids Apex CPU time limits per transaction. (2) Large Quote Experience: Enable in Package Settings to switch to a table-based configurator that renders without the full Angular configurator framework — significantly faster for large line counts. (3) Product Filters: Implement narrow product filters so reps only see relevant products in the catalog, reducing the number of products loaded into the configurator. (4) Defer Calculations: Use the "Recalculate" button pattern instead of real-time calculation on every change — configure the quote to require explicit recalculation. (5) Async CPQ API: For quotes generated programmatically (integrations, bulk renewal), use the CPQ Calculate API asynchronously via a Queueable or Batch Apex job. (6) Limit Price Rules and Product Rules: Each rule adds evaluation overhead; audit and combine rules where possible. (7) Quote Line Groups: Organise lines into groups to improve UI rendering performance and reduce the number of lines visible in each section.

CPQ configuration testing requires a structured approach: (1) Sandbox-First Development: All CPQ configuration (products, rules, templates, package settings) should be built and tested in a full or partial sandbox before promotion. (2) Unit Testing Pricing Scenarios: Create test quotes covering every pricing scenario — each discount schedule tier, each price rule condition, each product rule action. Verify the pricing waterfall at each step. (3) Bundle Configuration Testing: Test all option combinations including required options, constraints (requires/excludes), feature min/max, and selection rules. Verify edge cases like zero quantity and maximum quantity. (4) End-to-End Lifecycle Testing: Create a quote → contract it → generate an amendment → generate a renewal. Verify subscription records, twin field mapping, and delta quantity calculations. (5) Output Document Testing: Generate PDFs for all template variations and record types; check conditional sections, line column formatting, and grouping. (6) Permission Testing: Test as a CPQ User (not Admin) to catch FLS and permission issues. (7) Deployment: Use Change Sets, Gearset, or Copado to move configuration metadata; note that CPQ managed package records (Price Rules, Product Rules, Discount Schedules) are data — use Data Loader or a data migration tool, not Change Sets, to move them between environments.

Guided Selling in CPQ presents a questionnaire-style wizard to sales reps that recommends products based on their answers. Configuration: (1) Process Input Records (SBQQ__ProcessInput__c): Define the questions (e.g., "What industry is the customer in?" or "How many users?"). Each input has a data type, label, and optional default value. (2) Process Input Conditions: Determine which follow-up questions appear based on prior answers (branching logic). (3) Product Recommendation Mapping: Process Input values are mapped to Product Filter criteria — the wizard filters the product catalog to show only the matching products. The rep selects from the recommended products and adds them to the quote. Product Configurator (the standard bundle configurator): Once a bundle product is added to the quote, the configurator opens showing features, options, and real-time pricing. Option constraints, product rules, and custom scripts all execute within the configurator. Guided Selling and the Product Configurator work together to reduce configuration errors and shorten the quoting cycle.

Summary Variables (SBQQ__SummaryVariable__c) perform aggregate calculations across all quote lines or a filtered subset, returning a single value that can be used in Price Conditions or Price Actions. Configuration: (1) Source: The quote line field to aggregate (e.g., Net Total, Quantity, Custom Field). (2) Type: The aggregation function — SUM, COUNT, MAX, MIN, or AVERAGE. (3) Filter Field / Value: Optionally restrict the aggregation to lines matching a condition (e.g., only lines where Product Family = "Hardware"). Use cases in Price Rules: (a) If the total quote value (SUM of Net Total) exceeds $500,000, apply an additional 5% quote-level discount — the Price Condition references the Summary Variable. (b) If the count of Professional Services lines is greater than 3, set a capped price on additional lines. (c) Percent of Total pricing on support products often uses a Summary Variable summing the platform product net totals. Summary Variables are evaluated during the CPQ calculator run and are always computed before Price Rule actions that reference them.

Salesforce Billing is a separate managed package that extends CPQ to automate the invoice-to-cash cycle. Integration overview: (1) Orders from CPQ: When a CPQ quote is contracted, it generates Salesforce Orders and Order Products. Billing picks up these orders as the billing source. (2) Billing Schedules: Billing defines when invoices are generated — monthly, quarterly, annually, or on a custom schedule — per order product. (3) Invoice Generation: Billing automatically creates Invoice records (blng__Invoice__c) aggregating line items from the billing schedule. Invoices can be auto-posted or held for review. (4) Payment Processing: Billing integrates with payment gateways to process credit card or ACH payments against invoices. (5) Usage-Based Billing: Usage records (metered consumption) can be fed into Billing to generate usage-based invoice lines. (6) Revenue Recognition: Billing can post revenue to Salesforce Revenue Cloud or export to ERP systems. The CPQ → Billing data flow is: Quote → Contract → Order → Billing Schedule → Invoice → Payment. A CPQ Specialist should understand where CPQ's responsibility ends (contracted order) and Billing's begins (invoice generation onwards).

Salesforce Revenue Cloud is Salesforce's unified revenue platform combining CPQ, Billing, and related products into a cohesive solution for the entire revenue lifecycle. Key relationships: (1) CPQ is a component of Revenue Cloud: Salesforce CPQ (formerly Steelbrick CPQ) handles configure-price-quote; it is the quoting engine within Revenue Cloud. (2) Revenue Lifecycle Management (RLM): Salesforce has introduced a next-generation, native (non-managed-package) CPQ solution called Revenue Lifecycle Management built on the core Salesforce platform with a new Product Catalog object model. RLM is Salesforce's long-term direction to replace the managed package CPQ. (3) Transition Path: Customers on legacy CPQ package can continue using it; Salesforce is investing in migration tooling and feature parity for RLM. (4) Revenue Cloud includes: CPQ + Billing + Subscription Management + Revenue Intelligence (CRM Analytics for revenue reporting). (5) For CPQ Specialists, understanding this positioning is important: new implementations may start with RLM/Revenue Cloud rather than the managed package CPQ, while existing large deployments will remain on package CPQ for years.