In the evolving landscape of B2B and B2C commerce, businesses demand highly flexible, scalable, and industry-specific Configure, Price, Quote (CPQ) solutions. Salesforce Industries CPQ—formerly Vlocity—delivers exactly that, enabling enterprises to streamline complex selling processes with precision and speed. At the heart of this solution lies the Vlocity Product Catalog (VPC), a metadata-driven framework that defines how products, pricing, rules, and UI components work together to deliver a seamless quoting experience. This blog breaks down the major components of the VPC, offering a clear understanding of how products are modeled, priced, configured, and presented across industries like telecom, insurance, energy, and healthcare.
Components of the Vlocity Product Catalog (VPC) in Salesforce
Product (Offering)
Represents a commercial or technical item (product or service) that can be sold. It is the core building block in quotes/orders, capturing what the customer wants to purchase. In Vlocity, a “Product” (often called a product offering) is what is offered to customers, typically tied to pricing and a product specification.
Product Attribute
A characteristic or property of a product that defines its features and can influence a buyer’s decision (for example: color, size, speed). Product attributes provide a flexible way to extend product definitions (stored in a JSON blob on the Product record for efficiency). These attributes can drive product configuration and pricing logic.
Product Specification
The detailed blueprint of a product’s definition, separate from any commercial pricing. A product specification captures all the technical or functional details of a product (name, features, attributes, etc.), essentially what the product is. One or more sellable product offerings can be based on a single product specification (the offers “realize” the spec by adding pricing and market data). This separation allows reusability – the specification defines the product, while the product offering adds commercial info (like price, availability).
Product Relationship
Defines how products relate to each other in the catalog, whether in a bundle structure or via rules. For example, in a bundle (hierarchical model), you have parent–child product relationships with cardinality rules (child components that belong under a parent). There are also dependency relationships (linear model), such as “Relies On” relationships indicating one product depends on another. Product relationships cover use-cases like optional add-ons, inclusions/exclusions, prerequisites or auto-added products – ensuring the product configuration is valid and structured.
Price List
A container (catalog) of pricing information, analogous to a price book. Each Price List corresponds to a Salesforce Price Book and usually represents a market or region’s set of prices. It holds all the pricing entries (base prices, costs, discounts, etc.) for products and promotions in that context (e.g. a Retail price list vs. a Wholesale price list).
Price List Entry (PLE)
An entry that defines the price of a specific product on a given Price List. It associates a product with a pricing element or amount, along with details like currency and effective dates. In other words, a price list entry is like a Salesforce Price Book Entry – it’s the record of “Product X costs Y (in currency Z) on this price list”. (Vlocity allows multiple price list entries per product for different charge types or time periods, whereas core Salesforce typically has one price book entry per product per price book.)
Pricing Element
The fundamental price component that combines a price type with an amount (and optionally a formula or matrix lookup). A pricing element ties a Pricing Variable (e.g. one-time charge, monthly recurring charge, discount, cost, etc.) to a price value or calculation. In essence, it indicates a charge, cost, or adjustment on a product, bundle, or promotion. For example, a product’s pricing might include a one-time fee and a monthly fee – each of those is a pricing element (one-time charge, recurring charge).
Calculation Matrix
A configurable lookup table (matrix) of data used for complex pricing or logic. A calculation matrix is structured with input columns (criteria/dimensions) and output columns (results) and can store multiple rows and versions. The matrix acts as a reference table that the system can query to return a value based on given inputs. For instance, a matrix might map usage ranges to prices, or map product attributes to a discount percentage – when the CPQ engine needs a value, it “looks up” the matrix with the relevant inputs to get the output.
Calculation Procedure
A set of formula-like instructions that perform calculations to derive a result (often a price). In Vlocity CPQ, a calculation procedure executes a series of calculations using matrix lookups, variables, and constants. It can call one or more calculation matrices and apply logic to compute things like total price, tax, or discounts. Calculation Procedures provide a declarative way to implement complex pricing algorithms (e.g. tiered pricing, nested formulas) without coding – the procedure orchestrates how to use matrix data and math to arrive at a final calculation.
Context Rule
A rule that evaluates contextual conditions to qualify or filter products and pricing in the cart. Context rules determine when a certain rule set or action applies, based on who the customer is, what’s in their cart, date/locale, or other factors. They are often used to enforce eligibility or availability – for example, a context rule can ensure that a promotion only applies for customers in a certain region, or prevent a product from being selectable if prerequisites aren’t met. In the Industries CPQ cart, context rules can qualify (enable/disable) products, promotions, price list entries, or even apply penalties, all driven by the current context.
Compatibility Rule
A type of rule (in the “Advanced Rules” framework) focused on product compatibility and configuration logic. Compatibility rules ensure that selected products are allowed together and configure required product combinations. For example, a compatibility rule might automatically add a required related productwhen a base product is chosen, or conversely prevent two conflicting products from being in the same bundle. Essentially, these rules maintain valid product sets – enforcing that only compatible options go together (and guiding users by adding or restricting items based on the rule).
Rule Set
A container for grouping and executing rules. In Vlocity CPQ, a rule set can hold one or multiple context rules (or other rules) and is attached to products, promotions, or the cart so that all its rules run when triggered. The rule set has an associated trigger event (like “on add to cart” or “on price calculate”) and conditions under which it fires. By bundling rules into a set, you can manage them together – for instance, a “Mobile Plan Eligibility Ruleset” might contain several context rules for checking customer eligibility, all of which execute as a group when a mobile plan product is being configured.
Promotions
Special product offerings that provide discounts or deals under certain conditions. A promotion in Vlocity is modeled as a product (or bundle) that usually has an adjustment to price (like a discount) and is often time-bound or targeted. Promotions are created for a limited time period, specific customer segment, or a particular set of products. For example, a promotion might be “Buy one get one free for this month” or “10% off for students on Plan X”. In the catalog, promotions can be configured with their own pricing (often negative adjustments or override prices) and use context rules to determine eligibility and timing.
Coverage Product
In insurance industry models (supported by Vlocity), a Coverage Product represents an insurance coverage component that is part of an overall policy product. It “covers” a specific risk or item. For example, in an Auto Insurance Policy product, you might have coverage products like Collision Coverage, Liability Coverage, etc., each with its own attributes (coverage limits, deductibles). Coverage products are linked to the main insurance product to define what is insured. Essentially, a coverage product is not sold standalone to the end-customer, but is a child component that defines one aspect of coverage under an insurance offering. It inherits configuration from a Coverage product specification and ensures that policy products are modular (you can add or remove coverages as needed for a quote).
Object Type
A template or class definition for products (and other catalog objects) that allows inheritance of common fields and attributes. A Product Object Type defines a reusable set of properties (custom fields, attribute definitions, page layout setup) that will apply to all product specifications of that type. By grouping products with similar characteristics under an Object Type, you achieve consistent behavior and easier management – for instance, you might have an object type “Smartphone” that pre-defines attributes like Screen Size, OS, Memory, etc., which every smartphone product spec will automatically have. Object Types thus help enforce structure and reuse in the product catalog.
Field Mapper
A declarative tool for mapping and transforming fields between objects during the order lifecycle (asset-based ordering processes). Field Mapper is used to automatically transfer data between records like Opportunities → Quotes, Quotes → Orders, Orders → Assets, and back, without needing custom code. It essentially lets you configure how field values should carry over or convert when a quote becomes an order, an order becomes an asset, etc. This is crucial for keeping data consistent across the CPQ lifecycle (for example, ensuring a custom field on Quote copies to a field on Order). Field Mapper configurations define the source fields, target fields, and any transformation logic (such as value mappings) for the data copy.
OmniStudio DataRaptor
A declarative data integration tool (part of OmniStudio) used to extract, transform, and load data in Salesforce Industries processes. DataRaptors allow you to read data from Salesforce, write data to Salesforce, and manipulate data in between – all without code. For instance, a DataRaptor Extract can pull account and asset information to display in an OmniScript, a DataRaptor Transform can mash up or calculate data in JSON, and a DataRaptor Load can save form inputs to multiple Salesforce objects. DataRaptors act as the main way to get data in and out of CPQ/OmniStudio components, functioning like configurable ETL modules that map fields to JSON and vice versa.
OmniStudio Integration Procedure
A server-side, declarative process engine in OmniStudio used to execute multiple actions in a single transaction. Integration Procedures are essentially custom scripts (built via configuration) that can perform complex logic – they read/write Salesforce data, call external APIs, execute calculations, and apply conditional logic, all without user interaction. They are optimized for performance and often invoked from OmniScripts or even from APIs to do heavy-lifting in the background. For example, an Integration Procedure might retrieve product prices (via DataRaptor), apply discounts (via a calculation procedure), and return a quote summary – all in one server call. Designers can orchestrate steps and transformations graphically, making Integration Procedures easier to maintain than equivalent Apex code.
OmniScript
A guided user flow (OmniStudio component) that provides a step-by-step UI for complex processes. An OmniScript is essentially a dynamic, interactive form or wizard that leads users through a business process with branching, inputs, and automated actions. It’s comparable to a Salesforce Flow but offers more flexibility in UI/UX (using Lightning Web Components for a branded experience). In Industries CPQ, OmniScripts are used for things like guided selling or service enrollment – for example, an OmniScript could walk an agent through configuring a telecom package: choosing a base plan, selecting add-ons, collecting customer info, then reviewing and submitting the order. OmniScripts leverage actions (like DataRaptor calls, calculations, or even sub-scripts) at each step, enabling complex logic while keeping the user interface friendly.
FlexCard
A UI component from OmniStudio used to display information contextually in a concise card format. FlexCards present at-a-glance data and provide quick actions in a visually appealing way. They can aggregate data from multiple sources (Salesforce records, DataRaptors, etc.) and are typically used to summarize key information for an agent or customer. For instance, a FlexCard might show a customer’s profile with relevant details and buttons to update info or start a process. FlexCards are highly flexible: they support formatting, conditional rendering, and can be embedded in Lightning pages or even within OmniScripts. They often serve as “mini dashboards” or info panels – e.g. showing an account’s current services and a link to upgrade, all within a compact card on a CPQ cart or account page.
Each of these components plays a distinct role in product modeling and configuration for Salesforce Industries CPQ. Together they enable complex products (with attributes and hierarchical specifications), dynamic pricing calculations, and robust rules for eligibility and compatibility – all delivered through flexible OmniStudio-driven user experiences. The Vlocity Product Catalog’s modular approach (Products/Specs, Pricing elements, Rules, etc.) allows businesses to configure highly tailored CPQ behavior without writing custom code, using industry best-practice frameworks.
Also Read: Vlocity Environment Variable Guide with Examples and Use Cases
Conclusion
The Vlocity Product Catalog is more than just a collection of products and prices—it’s a robust, declarative system that allows for sophisticated modeling of commercial offerings, dynamic pricing, and guided selling experiences. Each component, from Product Specifications to Pricing Elements, Rules, and OmniStudio tools, plays a critical role in ensuring CPQ processes remain efficient, accurate, and industry-tailored. By mastering the building blocks of the VPC, organizations can accelerate time-to-market, reduce configuration errors, and empower sales and service teams with the agility they need in today’s competitive environment.
Sources: Official Salesforce Industries documentation and knowledge resources.
