A technical guide for Salesforce architects, consultants, and product teams building on Revenue Cloud Advanced
By : Ajay Pratap Singh
Introduction
Picture this: a Salesforce implementation team sits down to connect their product catalog to a new Agentforce autonomous quoting workflow. The concept is straightforward — surface the right product to the right customer, generate a quote, done. Two weeks later, they are still debugging API bridges between a managed package and the core platform. The catalog data is there. The AI is there. The package boundary is the problem.
This is the quiet cost of staying on EPC past its natural lifecycle. The Enterprise Product Catalog did what it promised — it brought enterprise-grade product management to telecommunications, utilities, and media operators at a time when Salesforce’s native platform simply could not match the complexity those industries needed. For many organisations, EPC has been the backbone of their commercial operations for the better part of a decade.
But Salesforce’s platform has not stood still. Product Catalog Management, introduced as part of Revenue Cloud Advanced and now central to Agentforce Revenue Management, delivers the same conceptual power as EPC — classification-based product templates, attribute-driven configuration, layered pricing rules, catalog scoping — built natively into the Salesforce core. No managed package. No separate upgrade cycle. No API bridge to cross before AI can reach your product data.
This guide walks through both systems at a component level, maps every major EPC construct to its PCM equivalent using a concrete Fibre broadband migration scenario, and gives the architectural and strategic context that teams need to plan and execute the migration with confidence.
Understanding EPC: Components in Detail
EPC is bundled with three Salesforce Industry Clouds — Communications Cloud, Energy & Utilities Cloud, and Media Cloud. Its architecture spans three functional layers: product design, pricing configuration, and business rules. Together these layers give catalog teams a complete toolset for modeling, pricing, and governing even the most complex product portfolios.
Before exploring the individual components, it helps to understand the two interfaces through which catalog administrators interact with EPC on a daily basis.
EPC Architecture: Three Functional Layers
- Business Rules Layer: Cardinality · Qualification · Penalty · Configuration · Pricing Rules · Decomposition
- Pricing Configuration Layer: Price Lists · Pricing Components · Promotions · Discounts · Matrix Pricing · Pricing Plan
- Product Design Layer: Picklists · Attribute Categories · Attributes · Object Types · Layouts · Specs · Offers
EPC Interface: Where Catalog Work Happens
Product Designer
The Product Designer is EPC’s primary working environment, built on Lightning Web Components. A left-hand navigation menu gives catalog administrators direct access to every entity in the data model — from picklists at the foundation all the way up to sellable offers at the top. It is the interface Salesforce recommends for all new EPC implementations and the one most implementation teams use for day-to-day catalog management.
Product Console
The Product Console is an older dashboard-style interface built on Angular. It presents catalog entities in a broader overview format that some teams prefer for bulk review tasks. Both surfaces operate on the same underlying data model, and teams often use them in parallel — the Product Console for reviewing and navigating large volumes of specs and offers, the Product Designer for detailed editing and creation.
A separate Pricing Designer sits alongside both and handles all pricing configuration independently, giving pricing analysts their own workspace without disrupting the product team’s view.
Product Design Components
1. Picklist
When a product attribute presents users with a fixed set of options, those options are defined through an EPC Picklist. These are custom objects in the Vlocity namespace — distinct from standard Salesforce picklist fields — and support text, number, Boolean, date, and date-time value types.
The defining design principle of EPC Picklists is reusability. A ‘Contract_Term’ picklist defined once with values of 12, 24, and 36 months can be simultaneously referenced by a residential broadband Object Type, a business leased line Object Type, and a mobile SIM-only Object Type. Updating available contract terms across the entire catalog means editing a single record rather than hunting through individual product configurations.
2. Attribute Category
Attribute Categories impose structure on what can otherwise become an overwhelming list of product characteristics. They group related attributes under a named heading and serve two distinct purposes: organising attributes for catalog administrators at design time, and presenting structured navigation panels for agents during CPQ configuration sessions.
In the Industries CPQ Cart, categories appear as collapsible section headings in the Filter and Configuration panels. An operator selling enterprise connectivity might define ‘Access Technology’, ‘Service Performance’, and ‘Commercial Terms’ as categories — giving agents an organised configuration experience rather than a flat scroll through every available attribute. Every attribute in EPC must belong to a category; uncategorised attributes are not permitted in the data model.
3. Product Attribute
Attributes capture the configurable or descriptive properties of a product. A standard SIM card with no configuration options might carry no attributes at all, while an enterprise router or cloud security bundle might carry dozens — technical specifications, commercial terms, and configuration options all living alongside each other in the same attribute framework.
EPC stores attribute values as an aggregated JSON blob on the Product2 record rather than in discrete custom fields. This makes the attribute model highly flexible — new attributes can be added without schema deployments — but it means attribute data can only be reliably read and written through Industries CPQ and Order Management tooling. Raw SOQL against Product2 will not return attribute values in a usable format.
4. Product Object Type
Object Types are the structural backbone of EPC’s product design layer. Each Object Type defines the reusable template of fields, attributes, and layouts shared by a group of related Product Specifications — eliminating the need to reconfigure attributes from scratch for every new product.
Object Types support multi-level inheritance. A top-level ‘Residential_Access’ Object Type might carry attributes common to all home services — installation address, contract term, and service start date. Child Object Types ‘FTTP_Residential’ and ‘Fixed_Wireless_Residential’ each inherit those base attributes and add their own technology-specific characteristics. Products built from ‘FTTP_Residential’ inherit the full combined attribute set from both their own type and every ancestor in the hierarchy — without duplication in the data model.
Object Type Inheritance — Example
Residential_Access (Parent OT) → inherits → FTTP_Residential (Child OT)
Attributes: Address, Contract Term, Start Date → adds → + Download Speed, Router Model, Technology Type
FTTP_Residential OT → creates → Product Spec: FTTP_100Mbps
5. Object Type Layout
Object Type Layouts control how attributes and fields are presented during product configuration. They function like field-level page layouts scoped to an Object Type — defining sections, column counts, field sequence, and tab-key navigation behaviour within each section.
A single Object Type can carry multiple layouts: one optimised for the Product Designer interface used by internal catalog administrators, and another configured for the agent-facing configuration panel in the CPQ Cart. This separation allows catalog teams to surface different levels of detail in different contexts without maintaining separate product configurations.
6. Product Specification
A Product Specification is where the abstract template of an Object Type becomes a concrete product definition. The catalog administrator selects an Object Type and populates specific values for its inherited attributes — a ‘FTTP_Residential’ Object Type becomes a ‘FibreHome_100Mbps’ Product Spec when download speed is set to 100Mbps, router model to a specific SKU, and technology type to FTTP.
Product Specs are stored as records on Salesforce’s standard Product2 object, making them queryable through standard platform tooling. However, a Spec alone does not appear in a customer quote or order — it is the technical definition of a product. The commercial layer — pricing, promotions, eligibility, and catalog assignments — is added at the Offer level.
7. Product Offer
The Product Offer is the commercial face of a product — visible in the CPQ Cart, browsable on self-service portals, and line-itemised on quotes and orders. An Offer is built from a Product Spec and layers on everything needed to make it commercially complete: price, validity window, applicable promotions, eligibility conditions, and catalog assignments.
One Spec can give rise to multiple Offers. ‘FibreHome_100Mbps’ Spec might generate a standard 12-month offer at AED 149/month, a discounted 24-month offer at AED 129/month, and a business-tier offer at AED 199/month with an SLA add-on. Offers support simple flat products and complex bundle structures with nested child offers. Every Offer must have at least one price entry before it can appear in a cart.
Pricing Configuration Components
1. Pricing Components
Pricing in EPC is not a single field — it is a structured set of Pricing Components, each representing one distinct commercial charge. A component can be a recurring monthly fee, a one-time activation charge, an installation surcharge, or a percentage-based promotional discount. Components can be denominated in currency or loyalty points, and each is tagged with a charge type — standard, penalty, or adjustment — that controls how it appears on invoices and how it flows through order management.
This decomposed design means pricing teams can update individual charge elements independently. Changing the installation fee from AED 99 to zero during a promotional period requires editing a single Pricing Component — not regenerating offers or touching the product specification.
2. Price List
A Price List is how product offers become selectable in the Industries CPQ Cart. Every offer that should be quotable must be assigned to an active Price List. Each Price List links to a Salesforce Price Book — most implementations use a single Price Book for the entire catalog, with multiple Price Lists layered on top for different channels or customer segments.
Price Lists support effective-dated pricing — a standard price active from January, a promotional price running March through April, and the standard price resuming automatically in May, all configured in advance without manual intervention at go-live. Context rules applied at the Price List level determine which list is selected at runtime based on the quoting context: customer segment, sales channel, geographic territory, or any other available attribute.
3. Cost and Margin
EPC allows product costs to be configured alongside prices, enabling margin visibility directly within the CPQ Cart. Costs follow the same one-time or recurring classification as charges. When an agent builds a quote, the cart calculates and displays the margin for each line item and for the overall deal — giving agents real-time commercial guardrails, particularly valuable in B2B environments where bespoke pricing is common and margin floors need to be enforced at point of sale.
4. Promotion
Promotions are pre-configured commercial incentives — time-bound benefits such as discounted prices, waived fees, or bonus services — associated with individual offers or bundle structures. Multiple promotions can coexist on a single offer, and agents can stack applicable promotions in a cart where business rules permit. Promotions are distinct from discounts in EPC: promotions are campaign-level constructs configured by product and pricing teams, while discounts are agent-initiated or account-level reductions applied at order time.
5. Discount
Discounts in EPC are price reductions at the order or account level rather than the campaign level. EPC maintains a clear distinction between two types. A contractual discount is tied to a service agreement and persists for the duration of the contract — early cancellation may trigger a penalty to recover the discount value. An ad hoc discount is a one-time reduction applied to a specific order with no ongoing commitment or recovery mechanism. This distinction feeds directly into penalty rule configuration and billing reconciliation.
6. Attribute-Based Pricing (Matrix Pricing)
Attribute-Based Pricing solves a catalog management problem that appears repeatedly in complex product portfolios: how to charge different prices based on a configuration choice without maintaining a separate offer for every variant.
Rather than building twenty separate offers for an enterprise leased line at 10Mbps, 50Mbps, 100Mbps, 500Mbps, and 1Gbps, a single offer carries a pricing matrix that maps each bandwidth value to its corresponding monthly charge. EPC supports three matrix types: Standard matrices price a product using its own attributes; Source/Target matrices price a child product based on attributes of a different product in the same bundle; Range matrices trigger a price when an attribute value falls within a defined numeric band.
Best Practice: When to Use Matrix Pricing vs Separate Offers
Use matrix pricing when products share the same commercial structure and differ only in a quantitative attribute like speed, storage, or capacity. Create separate offers when products differ in eligibility rules, promotional applicability, or fulfillment paths — because matrix pricing cannot scope business rules per attribute value. Mixing the two approaches is where most EPC catalog teams accumulate technical debt.
7. Pricing Plan
The Pricing Plan is the orchestration engine controlling the sequence in which all pricing logic is evaluated during a CPQ session. Salesforce ships EPC with a default plan covering base price lookup, discount application, promotion evaluation, and tax calculation in sequence. Architects can reorder steps, disable those not relevant to the implementation, and inject custom steps that call external APIs — such as a wholesale cost lookup from a network partner — at specific points in the evaluation chain.
Business Rules Components
1. Cardinality Rules
Cardinality rules set the quantity constraints on products within a bundle. Child cardinality defines the default, minimum, and maximum quantity for a specific child product within its parent bundle. Group cardinality sets aggregate min/max constraints across all children at a given bundle level — for example, requiring at least one and no more than four security modules to be selected from an available set, regardless of which specific modules the customer chooses.
2. Qualification Rules
Qualification rules control which products and promotions are visible based on customer or context characteristics. By default, every offer on a Price List is visible to all customers accessing that list. Qualification rules introduce conditional visibility — surfacing or suppressing offers based on criteria such as existing service assets, account type, channel, or customer segment.
A ‘FibreUpgrade_Premium’ offer might only appear when the customer’s asset record shows an active legacy DSL service. A promotional bundle might be restricted to accounts where the tenure field exceeds 24 months. Qualification rules allow catalog teams to create contextually relevant product experiences without maintaining separate catalogs per segment.
Best Practice: Qualification Rules vs Multiple Catalogs
A common design decision in EPC implementations is whether to scope product visibility through qualification rules on a single catalog or through separate catalogs per channel or segment. Qualification rules are generally preferable — they reduce catalog maintenance overhead and allow a single offer record to be reused across contexts. Multiple catalogs make sense when the product sets are genuinely distinct and need to be managed by separate teams.
3. Penalty Rules
Penalty rules define the financial consequence of early contract exit or premature product disconnection. They apply specifically to MACD (Move, Add, Change, Disconnect) orders involving contracted assets with a defined commitment period.
When a customer requests a disconnect that triggers an early exit, EPC evaluates applicable penalty rules, calculates the amount owed, and surfaces it in the CPQ Cart. The penalty charge flows through to billing as a one-time charge on the closing invoice. Penalty rules are closely coupled with promotional discounts — a 30% discount offered in exchange for a 24-month commitment typically carries a penalty rule that recovers a portion of that discount value if the customer exits before the commitment period ends.
4. Configuration and Compatibility Rules
Configuration rules govern product and attribute behaviour during a cart or configuration session — at both the product and attribute levels. At the product level, they define which products can coexist, which are incompatible, and which should be automatically added or removed when another product is selected. At the attribute level, they control which values are available or visible based on the current values of other attributes.
Consider a smart home bundle where the customer selects a security camera model. If the chosen model only supports 5GHz WiFi, a configuration rule automatically excludes 2.4GHz-only router options from the router selection — preventing technically invalid combinations without requiring agents to memorise compatibility matrices.
5. Pricing Rules
Pricing rules make targeted adjustments to a product’s price when specific cart conditions are satisfied. They are distinct from promotions (pre-configured campaigns) and discounts (account-level reductions). EPC supports fixed pricing (overriding base price entirely), conditional pricing (discount or surcharge triggered by a rule condition), bundled pricing (adjustment applied when specific product combinations are present), promotional pricing (time-bound reduction), and custom pricing (bespoke Apex or Integration Procedure logic for scenarios the standard types cannot handle).
6. Rules Framework: Context Rules vs Advanced Rules
EPC provides two implementation pathways for business rules. Context Rules are the recommended default — they evaluate named context attributes (account type, channel, geography, asset status) against defined conditions and return a result that drives product visibility, pricing selection, or eligibility determination. Context Rules are configured through the EPC UI without code and cover the majority of real-world use cases.
Advanced Rules offer lower-level, more granular rule definition for scenarios requiring multi-step conditional logic, cross-product attribute comparisons, or custom rule actions. Advanced Rules can be combined with Context Rules — teams typically use Context Rules wherever they suffice and reach for Advanced Rules only where the complexity genuinely demands it.
Best Practice: Start with Context Rules, Graduate to Advanced
Unless a requirement demonstrably cannot be met by Context Rules, start there. Context Rules are faster to build, easier to test, and simpler for future administrators to maintain. The cost of Advanced Rules is not in initial development — it is in the ongoing maintenance burden when the catalog evolves and rules need to be updated by someone who did not build them originally.
7. Decomposition Rules
Decomposition rules operate at the boundary between the commercial catalog and the technical fulfillment layer, and are evaluated by Industries Order Management rather than CPQ. When a customer order is submitted, decomposition rules map commercial products to their underlying technical fulfillment products and tasks — translating what a customer bought into what the network or operations team actually provisions.
A ‘FibreHome_100Mbps’ commercial offer decomposes into two technical tasks: Provision_FTTP_Access (network side) and Activate_ONT_Device (equipment side). Each task is a technical product in EPC’s technical catalog. Decomposition rules define the mapping, the sequencing, and any conditional branching — for example, routing installation orders through a different fulfillment path than upgrade orders for the same product.
Understanding PCM: Components in Detail
Product Catalog Management is the product-definition layer within Agentforce Revenue Management. Where EPC operates as a package layered on top of Salesforce, PCM is woven directly into the platform — its objects are native Salesforce records, queryable via SOQL, extensible via standard Apex and Flow, and visible in Schema Builder without any package-specific tooling.
It is worth clarifying one point: PCM functions as the central product repository for the Revenue Management stack — Salesforce Pricing, Transaction Management, and Order Management all draw from it. However, organisations with complex integration landscapes may still maintain product data in other systems and sync to PCM, particularly during phased migrations. Calling PCM the absolute ‘single source of truth’ is an aspiration that holds fully only once the migration is complete.
PCM Architecture: Native Salesforce Stack
- Agentforce / Einstein / Data Cloud: AI recommendations · Autonomous quoting · Predictive pricing
- Transaction Management + Order Management: Quoting · Ordering · Fulfillment orchestration
- Salesforce Pricing Engine: Price Books · Pricing Adjustments · Selling Models
- Product Catalog Management (PCM): Products · Classifications · Dynamic Attributes · Catalogs · Qualification Rules
- Salesforce Core Platform: Native objects · Flow · Apex · SOQL · Data Cloud integration
1. Product Catalog
A Catalog in PCM is the channel-facing container that organises products for discovery and purchase. PCM takes a deliberate approach of explicit assignment over inheritance — products are directly linked to catalogs with defined effective start and end dates, making it straightforward to scope availability per channel and period without tracing complex parent-child inheritance chains.
A single org might maintain a Retail_Consumer catalog for direct-to-consumer digital channels, a Partner_Reseller catalog for indirect sales, and a Migration_Legacy catalog containing transition offers for customers moving off legacy product lines. A product can appear in multiple catalogs simultaneously, each with independent effective dates if needed.
2. Dynamic Attributes
Dynamic Attributes are PCM’s mechanism for extending product definitions beyond the base Product2 field set — without touching the org’s schema. Where standard Salesforce products rely on custom fields for product properties, requiring a schema change and deployment for every new characteristic, PCM Dynamic Attributes are configuration-driven. Adding ‘Maximum Concurrent Streams’ as an attribute on a video streaming product requires no deployment: the attribute is created in PCM setup and linked to the relevant Product Classification.
Attributes are grouped into Attribute Categories, serving the same organisational purpose as their EPC counterparts. Attributes can be defined as configurable — the customer or agent selects a value during purchase — or fixed, with the value set at the product level and not adjustable at runtime.
3. Product Classification
Product Classifications are PCM’s equivalent of EPC’s Object Types — reusable structural templates that define the attribute set inherited by any product linked to them. A ‘Streaming_Service’ Classification carrying attributes for resolution quality, simultaneous screens, and supported devices can be used to create ‘StreamBasic’, ‘StreamStandard’, and ‘StreamPremium’ products — each inheriting the full attribute set automatically.
PCM Classifications support hierarchy: a parent ‘Digital_Service’ Classification can have child Classifications ‘Streaming_Service’ and ‘Cloud_Storage_Service’, each inheriting the parent’s common attributes and adding their own. The practical benefit is catalog velocity — introducing a new streaming tier means creating a product and linking it to the existing Classification. All the relevant attributes are immediately present without any re-definition.
Classification Hierarchy → Product Inheritance
Digital_Service (Parent Classification) → inherits → Streaming_Service (Child Classification)
Attributes: Billing Frequency, Territory → adds → + Resolution, Screens, Offline Downloads
Streaming_Service Classification → creates → Products: StreamBasic / StreamStandard / StreamPremium
4. Products
PCM products are Salesforce Product2 records enriched with Revenue Management metadata and linked to a Product Classification. The data model accommodates four product configurations covering the full commercial spectrum.
A Simple product is a standalone item with no hierarchy and no configurable options — a flat-rate monthly service or a one-time setup fee. A Bundled product groups multiple products under a parent, sold as a unit with defined required and optional children. A Static product or bundle is sold exactly as configured in the catalog with no modification at point of sale. A Configurable product allows specific elements to be adjusted during the quoting or buying process — child product selection within a bundle, attribute value specification, or quantity adjustment within cardinality limits.
Product Selling Models define how a product is commercially structured over time: as a one-time purchase, as an evergreen subscription with no defined end date, or as a term-defined contract with a specific commitment period. The Selling Model drives quote presentation, billing behaviour, and renewal handling.
5. Qualification Rules
PCM Qualification Rules control which products are visible to which customers in which contexts — mirroring EPC’s Qualification Rules in function while operating entirely through native Salesforce data. The default state in PCM is that all products in a catalog are visible to all users. Qualification Rules introduce conditional filtering.
Rules can be applied at the product level or at the category level, and they evaluate conditions drawn from any accessible Salesforce data — account fields, geographic data, contact attributes, or related record values. A product category containing 5G-only devices might be qualified out for customers whose service address falls outside a mapped 5G coverage zone. A promotional bundle might be restricted to accounts whose tenure field exceeds a defined threshold. The result is a dynamically personalised catalog experience shaped by real customer data — without separate catalog instances per segment.
6. Product List and Product Detail Pages
PCM provides two dedicated UI surfaces built into the Revenue Management experience. The Product List page presents the catalog hierarchy — categories, subcategories, and products within them — with keyword search for agents who know what they are looking for. The Product Detail page presents a selected product’s full commercial profile: attributes, classification, bundle structure, selling models, and pricing. These surfaces provide basic catalog browsing out of the box without requiring custom OmniScripts or Visualforce pages.
With both platforms mapped at the component level, the logical next step is to see how they translate to each other in practice — and what that translation means for a real catalog.
EPC vs. PCM: Side-by-Side
Deployment
EPC (Enterprise Product Catalog): Managed Package — Vlocity/Industries
PCM (Product Catalog Management): Native Salesforce — no package required
Core Constructs
EPC (Enterprise Product Catalog): Spec, Object Type, Picklist, Attribute, Offer
PCM (Product Catalog Management): Product Classification, Dynamic Attributes, Product
UI Surface
EPC (Enterprise Product Catalog): Product Designer (LWC) + Product Console (Angular)
PCM (Product Catalog Management): Revenue Management setup pages in core Salesforce
OmniStudio
EPC (Enterprise Product Catalog): Tightly coupled — essential for CPQ Cart & config flows
PCM (Product Catalog Management): Compatible — but not the only integration option
Industry Scope
EPC (Enterprise Product Catalog): Communications, Energy & Utilities, Media
PCM (Product Catalog Management): All Salesforce Industry Clouds + core commercial use cases
Pricing
EPC (Enterprise Product Catalog): Price Lists, Pricing Components, Matrix Pricing, Pricing Plan
PCM (Product Catalog Management): Salesforce Pricing engine with native Pricing Adjustments
Rules Engine
EPC (Enterprise Product Catalog): Cardinality, Qualification, Penalty, Config, Decomposition
PCM (Product Catalog Management): Qualification Rules, Selling Models, Order Terms
Fulfillment
EPC (Enterprise Product Catalog): Decomposition Rules → Vlocity Order Management
PCM (Product Catalog Management): Order orchestration via native Salesforce Order Management
Release Cadence
EPC (Enterprise Product Catalog): Managed package cycle — independent of core releases
PCM (Product Catalog Management): Standard Salesforce tri-annual release cycle
AI Readiness
EPC (Enterprise Product Catalog): Requires custom API bridge to Data Cloud
PCM (Product Catalog Management): Native Data Cloud + Einstein integration out of the box
Real-World Migration Example: A Fibre Broadband Portfolio
To make the component mapping concrete, this section walks through a real-world scenario: a residential internet service provider operating in the UAE that has built its entire catalog on EPC across three FTTP broadband tiers under the ‘FibreHome’ brand, sold through both a retail agent channel and a self-service web portal.
The migration described here covers every EPC component introduced in this article and shows exactly what the migration team had to do to move each one into PCM — including the decisions, trade-offs, and surprises they encountered along the way.
How the Catalog Was Built in EPC
The team began with a ‘SIM_Type’ Picklist carrying Physical SIM, eSIM, and Dual-SIM values for a companion mobile add-on. A ‘Network_Settings’ Attribute Category grouped the broadband technical characteristics. Under it, a ‘Download_Speed’ Attribute covered 100Mbps, 300Mbps, and 1Gbps tiers. A ‘Fibre_Residential’ Object Type combined Network_Settings attributes with commercial attributes for contract term and router model, with a two-column Object Type Layout organising fields into a Network tab and a Commercial tab.
Three Product Specs — FTTP_100Mbps, FTTP_300Mbps, FTTP_1Gbps — were built from the Fibre_Residential Object Type. Each Spec produced two Product Offers: a 12-month variant and a 24-month variant, giving six sellable offers in total. All were assigned to a ‘Residential_PL’ Price List linked to the B2C Price Book. Pricing Components defined AED 149/month recurring plus AED 99 one-time installation for the entry tier. Attribute-Based Pricing handled speed-tier pricing differences through a single matrix mapping each Download_Speed value to its monthly rate. A Pricing Rule applied a 15% discount when contract term was set to 24 months. A Qualification Rule restricted all offers to Residential account types. A Penalty Rule recovered 50% of the remaining contract value for early 24-month exits. A Decomposition Rule mapped each offer to two technical fulfillment tasks: Provision_FTTP_Access and Activate_ONT_Device.
EPC Configuration Summary — FibreHome Portfolio
Object Type: Fibre_Residential
Attributes: Download_Speed, Contract_Term, Router_Model
Specs: FTTP_100Mbps, FTTP_300Mbps, FTTP_1Gbps
Offers: 6 total (3 speeds × 2 contract terms)
Price List: Residential_PL → B2C Price Book
Pricing: AED 149–249/mo recurring + AED 99 one-time
Matrix Pricing: Speed-tier attribute matrix
Pricing Rule: 15% off for 24-month term
Qualification: Account_Type = Residential
Penalty: 50% early exit on 24-month contracts
Decomposition: Provision_FTTP_Access + Activate_ONT_Device per offer
The Full Component Migration Mapping
The table below maps every EPC component in the FibreHome catalog to its PCM counterpart, with specific migration actions for each:
Picklist
Telco Example in EPC: SIM_Type: Physical, eSIM, Dual-SIM
PCM Equivalent: Dynamic Attribute — value set on Classification
Migration Note: Values recreated as attribute options in PCM
Attribute Category
Telco Example in EPC: ‘Network Settings’ grouping Speed & Technology
PCM Equivalent: Attribute Category on Product Classification
Migration Note: Category structure preserved; mapped 1:1
Product Attribute
Telco Example in EPC: Download_Speed: 100Mbps, 300Mbps, 1Gbps
PCM Equivalent: Dynamic Attribute on ‘Broadband’ Classification
Migration Note: Inherited by all Broadband products automatically
Object Type
Telco Example in EPC: Fibre_Residential — shared by all FTTP products
PCM Equivalent: Product Classification: Fibre_Residential
Migration Note: Classification hierarchy replaces OT inheritance
Object Type Layout
Telco Example in EPC: 2-column layout: Network tab, Commercial tab
PCM Equivalent: Attribute groupings on Classification record
Migration Note: Recreated using PCM attribute category ordering
Product Spec
Telco Example in EPC: FTTP_100Mbps — blueprint, not yet sellable
PCM Equivalent: Product record linked to Fibre_Residential Classification
Migration Note: Product2 record with Classification reference
Product Offer
Telco Example in EPC: FibreHome_100_AED149 — sellable with pricing
PCM Equivalent: Product with Price Book Entry + Selling Model
Migration Note: Selling model set to term-defined, 12/24 months
Price List
Telco Example in EPC: Residential_PL linked to B2C Price Book
PCM Equivalent: Price Book — Residential with channel context rule
Migration Note: Context rule rebuilt using PCM qualification
Pricing Component
Telco Example in EPC: Recurring: AED 149/mo + One-time install: AED 99
PCM Equivalent: Price Book Entries — recurring + one-time charges
Migration Note: Two separate PBEs per product in PCM
Matrix Pricing
Telco Example in EPC: Speed tier pricing: 100Mbps=AED149, 1Gbps=AED249
PCM Equivalent: Attribute-based Pricing Adjustment in RCA Pricing
Migration Note: Rule triggers on Download_Speed attribute value
Pricing Plan
Telco Example in EPC: Custom step: 3rd party credit-check pricing API
PCM Equivalent: Pricing Procedure with custom Flow step
Migration Note: Flow action replaces Apex-based custom step
Cardinality Rule
Telco Example in EPC: Min 1, Max 3 add-ons per Fibre bundle
PCM Equivalent: Product Bundle child configuration — min/max qty
Migration Note: Configured at bundle product level in PCM
Qualification Rule
Telco Example in EPC: FibreHome offer: only for residential accounts
PCM Equivalent: PCM Qualification Rule on Product
Migration Note: Condition: Account Type = Residential
Penalty Rule
Telco Example in EPC: Early exit: recover 50% of remaining contract value
PCM Equivalent: Penalty logic via Order Contract Terms
Migration Note: Mapped to commitment period in native OM
Config/Compat Rule
Telco Example in EPC: If Router_Type = WiFi6, then WiFi5 is excluded
PCM Equivalent: Attribute dependency rule on Product Classification
Migration Note: Rebuilt using PCM attribute visibility rules
Pricing Rule
Telco Example in EPC: 15% off if contract term = 24 months
PCM Equivalent: Pricing Adjustment Rule in RCA Pricing engine
Migration Note: Triggered by Selling Model term selection
Decomposition Rule
Telco Example in EPC: FibreHome → Provision_FTTP + Activate_Router tasks
PCM Equivalent: Order Orchestration Flow in native Salesforce OM
Migration Note: Fulfillment steps mapped to OM orchestration
What the Migration Team Actually Did
The project began with a full Bulk API export of all FibreHome catalog data — Picklists, Attribute Categories, Attributes, Object Types, Layouts, Specs, Offers, Price Lists, Pricing Components, and all rule records. A Python transformation script converted each exported record into the format required by PCM’s REST APIs, mapping Spec fields to Product Classification attributes and Offer fields to Product2 records with Price Book Entries.
Product Classifications came first, establishing ‘Fibre_Residential’ with Dynamic Attributes mirroring the EPC Object Type’s attribute set. Products were created against the Classification. Each offer’s Pricing Components were split into two Price Book Entries — one for the recurring monthly charge and one for the one-time installation fee — since PCM does not use a composite Pricing Component object.
The Attribute-Based Pricing matrix required the most rebuild effort. In EPC it was a native Pricing Designer construct. In PCM it was recreated as three separate Pricing Adjustment Rules in the RCA Pricing engine — one per speed tier, each triggered by evaluating the Download_Speed attribute and applying the corresponding monthly rate. End-to-end quote generation was tested across all six speed and term combinations before the team moved on.
The Decomposition Rules presented the most architectural change. In EPC, they lived within the managed package and were evaluated by Vlocity Order Management. In PCM, the equivalent is a native Salesforce Order Orchestration Flow that fires on order creation and generates the two fulfillment tasks based on product type. This required active participation from the Order Management workstream — it could not be done by the catalog team alone.
Best Practice: Validate Pricing Before Anything Else Goes to UAT
In every EPC-to-PCM migration the team has observed, pricing validation is where the most defects surface. Matrix pricing translations, term-based discount rule logic, and one-time charge behaviour all behave subtly differently in PCM’s Pricing engine compared to EPC’s. Run automated quote generation tests covering every price combination before opening UAT — not during it.
Total elapsed time for the FibreHome portfolio migration: five weeks for a team of three, covering catalog transformation, pricing rebuild, OmniScript Integration Procedure repointing, and UAT across both channels. The pricing rebuild and validation accounted for roughly 60% of that time.
The Business Case for Migration
Every migration carries a cost. Development time, testing cycles, change management, and the inevitable discovery of complexity that was not visible in the planning phase. The question is not whether that cost is real — it is — but whether the cost of not migrating is higher. For most organisations on EPC, the calculus has shifted decisively toward migration.
Staying on the Platform Roadmap
Salesforce’s strategic investment in the commercial stack flows into PCM, Salesforce Pricing, and Agentforce Revenue Management — not into EPC maintenance. New capabilities such as AI-driven product recommendations, Agentforce autonomous quoting, and real-time Data Cloud product activation are being built on PCM’s native data model. Organisations remaining on EPC will find themselves progressively unable to adopt these capabilities without completing the migration they deferred.
Reducing Package Dependency Overhead
Managed packages introduce a persistent operational cost that is easy to underestimate until it accumulates. Every Salesforce release must be validated against the EPC package version. Every EPC package upgrade must be scheduled, sandbox-tested, and coordinated across teams before it can be applied to production. For organisations with large CPQ and Order Management implementations, this process can consume weeks per release cycle. PCM moves forward with the platform — no package upgrade scheduling required.
A Single Commercial Data Model
When product data lives natively in Salesforce, it becomes a first-class citizen of the entire platform. Reports can be built against product records without custom connectors. Flow can reference product attributes directly. Apex triggers can act on catalog changes in real time. The product catalog becomes part of the fabric of the org rather than a package island accessible only through proprietary APIs. This matters most for organisations building cross-cloud reporting, unified customer views, or AI-powered commercial workflows.
AI and Agentforce Readiness
PCM’s native architecture makes product data immediately consumable by Data Cloud and Einstein. Product Classifications, attributes, and catalog assignments can be unified with customer data to power next-best-offer recommendations, churn propensity models, and personalised pricing strategies. Agentforce autonomous agents can reason about PCM product data without custom integration layers. These capabilities represent the next wave of commercial differentiation — and they are only accessible through a native catalog foundation.
Challenges and Best Practices
A migration from EPC to PCM is manageable. It is not trivial, and teams that treat it as a straightforward lift-and-shift consistently encounter problems that slow the project significantly. The challenges below represent the most common patterns across implementations — and the best practices are grounded in what actually works, not what the project plan assumed would work.
Challenge: OmniScript and Integration Procedure Rework
The EPC and OmniStudio combination is tightly woven. FlexCards rendering product information, OmniScripts driving configuration flows, and Integration Procedures calling EPC catalog APIs all need to be updated when the underlying data source changes to PCM. This is a rebuild of the integration layer, not a configuration change. Scope OmniStudio rework as a dedicated workstream with its own timeline and resources — not as a downstream task to be addressed after catalog migration is complete.
Challenge: Pricing Model Translation
EPC’s Pricing Plan, Pricing Components, matrix pricing, and multi-layered rule types do not map one-to-one to PCM’s pricing model. The most reliable approach is to document every pricing scenario in plain language — ‘the price is AED X when condition Y is true, adjusted by Z% when condition W is also true’ — and rebuild each scenario in PCM from that specification. Reverse-engineering PCM configuration directly from EPC configuration introduces translation errors that are time-consuming to trace.
Challenge: Decomposition Rule Migration
Decomposition rules are often the last thing teams plan for and the first thing that causes production incidents. The migration from EPC decomposition rules to native Salesforce Order Orchestration Flows is an architectural change — not a configuration migration. It requires Order Management expertise alongside catalog expertise, and it must be tested with real MACD order scenarios, not just new-install orders, before cutover.
Best Practice: Component-Level Audit Before Anything Else
Run a complete inventory of every EPC component in the org before any migration work begins. Count picklists, attribute categories, attributes, object types, specs, offers, price lists, pricing components, matrix pricing configurations, and every rule type. Identify which are actively referenced by live products and which are orphaned legacy configuration. This audit drives the migration scope, surfaces complexity early, and creates the opportunity to retire catalog debt before carrying it into PCM.
Best Practice: Migrate by Product Domain in Phases
A single cutover of the entire catalog is a high-risk strategy regardless of how thorough the testing phase was. Phasing migration by product domain — starting with one product line, validating it fully in production, then proceeding — lets teams learn from the first domain before complexity scales. It also keeps the business operating on EPC for unchanged product lines during the migration, reducing commercial risk at each phase boundary.
Best Practice: Define a Clear ‘Done’ Criteria Before Starting
Before the first product domain goes live on PCM, agree on what ‘done’ means: which EPC objects are retired, which OmniStudio components are repointed, which test scenarios pass, and which reporting dashboards confirm that PCM data matches EPC baseline. Without a clear definition of done per phase, migrations tend to run indefinitely in a ‘mostly migrated’ state that is more complex to operate than either system alone.
Conclusion: The Platform Is Ready. Is Your Catalog?
EPC earned its place. For the operators and utilities providers that adopted it, it delivered a level of product catalog sophistication that transformed how they went to market on Salesforce — faster offer launches, configurable bundles that actually configured correctly, pricing rules that held up under real-world quoting complexity. That is not a small thing, and organisations should not underestimate the value of what they built on EPC before deciding how to approach this migration.
But the decision about what to build next is different from the decision about what to preserve from the past. Product Catalog Management is not a replacement for EPC in the sense of feature-for-feature substitution. It is a redesign of the same domain on a better architectural foundation — native platform objects, tri-annual release cadence, direct AI integration, no package boundary between the catalog and the commercial stack.
The strategic argument for migration has become more straightforward with every Salesforce release. Each release adds new capabilities — Agentforce product agents, Data Cloud product unification, Einstein pricing models — that are native to PCM and require significant custom integration work to reach EPC. The migration cost is a one-time investment. The cost of staying on EPC compounds with every release cycle.
For teams planning this journey today: start with the component-level audit described in this guide. Map every EPC object to its PCM equivalent. Build the transformation script before the migration timeline, not during it. Phase the rollout by product domain. Treat OmniStudio rework and decomposition rule migration as first-class workstreams, not afterthoughts. And invest in pricing validation — it is where the time goes.
The platform is ready. Organisations that complete this migration will find themselves operating on a commercial foundation that grows more capable with every release — without a single managed package upgrade cycle standing between them and what is next.