{"id":54,"date":"2026-06-23T06:03:50","date_gmt":"2026-06-23T06:03:50","guid":{"rendered":"https:\/\/www.encoderapps.com\/blog\/?p=54"},"modified":"2026-07-06T06:28:17","modified_gmt":"2026-07-06T06:28:17","slug":"leaving-the-package-behind-how-to-migrate-from-salesforce-epc-to-product-catalog-management-and-why-it","status":"publish","type":"post","link":"https:\/\/www.encoderapps.com\/blog\/leaving-the-package-behind-how-to-migrate-from-salesforce-epc-to-product-catalog-management-and-why-it\/","title":{"rendered":"From Legacy to Next-Gen: Migrating from Salesforce EPC to Revenue Cloud Advanced"},"content":{"rendered":"\n

A technical guide for Salesforce architects, consultants, and product teams building on Revenue Cloud Advanced

By<\/strong> : Ajay Pratap Singh<\/strong><\/h3>\n\n\n\n

Introduction<\/strong><\/h3>\n\n\n\n

Picture this: a Salesforce implementation team sits down to connect their product catalog to a new Agentforce autonomous quoting workflow. The concept is straightforward \u2014 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.<\/p>\n\n\n\n

This is the quiet cost of staying on EPC past its natural lifecycle. The Enterprise Product Catalog did what it promised \u2014 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.<\/p>\n\n\n\n

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 \u2014 classification-based product templates, attribute-driven configuration, layered pricing rules, catalog scoping \u2014 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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Understanding EPC: Components in Detail<\/strong><\/h3>\n\n\n\n

EPC is bundled with three Salesforce Industry Clouds \u2014 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.<\/p>\n\n\n\n

Before exploring the individual components, it helps to understand the two interfaces through which catalog administrators interact with EPC on a daily basis.<\/p>\n\n\n\n

EPC Architecture: Three Functional Layers<\/strong><\/h3>\n\n\n\n
    \n
  • Business Rules Layer: <\/strong>Cardinality \u00b7 Qualification \u00b7 Penalty \u00b7 Configuration \u00b7 Pricing Rules \u00b7 Decomposition<\/li>\n<\/ul>\n\n\n\n
      \n
    • Pricing Configuration Layer: <\/strong>Price Lists \u00b7 Pricing Components \u00b7 Promotions \u00b7 Discounts \u00b7 Matrix Pricing \u00b7 Pricing Plan<\/li>\n<\/ul>\n\n\n\n
        \n
      • Product Design Layer: <\/strong>Picklists \u00b7 Attribute Categories \u00b7 Attributes \u00b7 Object Types \u00b7 Layouts \u00b7 Specs \u00b7 Offers<\/li>\n<\/ul>\n\n\n\n

        EPC Interface: Where Catalog Work Happens<\/strong><\/h3>\n\n\n\n

        Product Designer<\/strong><\/h3>\n\n\n\n

        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 \u2014 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.<\/p>\n\n\n\n

        Product Console<\/strong><\/h3>\n\n\n\n

        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 \u2014 the Product Console for reviewing and navigating large volumes of specs and offers, the Product Designer for detailed editing and creation.<\/p>\n\n\n\n

        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.<\/p>\n\n\n\n

        Product Design Components<\/strong><\/h3>\n\n\n\n

        1. Picklist<\/strong><\/p>\n\n\n\n

        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 \u2014 distinct from standard Salesforce picklist fields \u2014 and support text, number, Boolean, date, and date-time value types.<\/p>\n\n\n\n

        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.<\/p>\n\n\n\n

        2. Attribute Category<\/strong><\/p>\n\n\n\n

        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.<\/p>\n\n\n\n

        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 \u2014 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.<\/p>\n\n\n\n

        3. Product Attribute<\/strong><\/p>\n\n\n\n

        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 \u2014 technical specifications, commercial terms, and configuration options all living alongside each other in the same attribute framework.<\/p>\n\n\n\n

        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 \u2014 new attributes can be added without schema deployments \u2014 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.<\/p>\n\n\n\n

        4. Product Object Type<\/strong><\/p>\n\n\n\n

        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 \u2014 eliminating the need to reconfigure attributes from scratch for every new product.<\/p>\n\n\n\n

        Object Types support multi-level inheritance. A top-level ‘Residential_Access’ Object Type might carry attributes common to all home services \u2014 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 \u2014 without duplication in the data model.<\/p>\n\n\n\n

        Object Type Inheritance \u2014 Example<\/strong><\/h3>\n\n\n\n

        Residential_Access (Parent OT)  \u2192  inherits  \u2192  FTTP_Residential (Child OT)<\/p>\n\n\n\n

        Attributes: Address, Contract Term, Start Date  \u2192  adds  \u2192  + Download Speed, Router Model, Technology Type<\/p>\n\n\n\n

        FTTP_Residential OT  \u2192  creates  \u2192  Product Spec: FTTP_100Mbps<\/p>\n\n\n\n

        5. Object Type Layout<\/strong><\/p>\n\n\n\n

        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 \u2014 defining sections, column counts, field sequence, and tab-key navigation behaviour within each section.<\/p>\n\n\n\n

        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.<\/p>\n\n\n\n

        6. Product Specification<\/strong><\/p>\n\n\n\n

        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 \u2014 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.<\/p>\n\n\n\n

        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 \u2014 it is the technical definition of a product. The commercial layer \u2014 pricing, promotions, eligibility, and catalog assignments \u2014 is added at the Offer level.<\/p>\n\n\n\n

        7. Product Offer<\/strong><\/p>\n\n\n\n

        The Product Offer is the commercial face of a product \u2014 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.<\/p>\n\n\n\n

        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.<\/p>\n\n\n\n

        Pricing Configuration Components<\/strong><\/h3>\n\n\n\n

        1. Pricing Components<\/strong><\/p>\n\n\n\n

        Pricing in EPC is not a single field \u2014 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 \u2014 standard, penalty, or adjustment \u2014 that controls how it appears on invoices and how it flows through order management.<\/p>\n\n\n\n

        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 \u2014 not regenerating offers or touching the product specification.<\/p>\n\n\n\n

        2. Price List<\/strong><\/p>\n\n\n\n

        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 \u2014 most implementations use a single Price Book for the entire catalog, with multiple Price Lists layered on top for different channels or customer segments.<\/p>\n\n\n\n

        Price Lists support effective-dated pricing \u2014 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.<\/p>\n\n\n\n

        3. Cost and Margin<\/strong><\/p>\n\n\n\n

        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 \u2014 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.<\/p>\n\n\n\n

        4. Promotion<\/strong><\/p>\n\n\n\n

        Promotions are pre-configured commercial incentives \u2014 time-bound benefits such as discounted prices, waived fees, or bonus services \u2014 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.<\/p>\n\n\n\n

        5. Discount<\/strong><\/p>\n\n\n\n

        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 \u2014 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.<\/p>\n\n\n\n

        6. Attribute-Based Pricing (Matrix Pricing)<\/strong><\/p>\n\n\n\n

        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.<\/p>\n\n\n\n

        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.<\/p>\n\n\n\n

        Best Practice: When to Use Matrix Pricing vs Separate Offers<\/strong><\/h3>\n\n\n\n

        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 \u2014 because matrix pricing cannot scope business rules per attribute value. Mixing the two approaches is where most EPC catalog teams accumulate technical debt.<\/p>\n\n\n\n

        7. Pricing Plan<\/strong><\/p>\n\n\n\n

        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 \u2014 such as a wholesale cost lookup from a network partner \u2014 at specific points in the evaluation chain.<\/p>\n\n\n\n

        Business Rules Components<\/strong><\/h3>\n\n\n\n

        1. Cardinality Rules<\/strong><\/p>\n\n\n\n

        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 \u2014 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.<\/p>\n\n\n\n

        2. Qualification Rules<\/strong><\/p>\n\n\n\n

        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 \u2014 surfacing or suppressing offers based on criteria such as existing service assets, account type, channel, or customer segment.<\/p>\n\n\n\n

        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.<\/p>\n\n\n\n

        Best Practice: Qualification Rules vs Multiple Catalogs<\/strong><\/h3>\n\n\n\n

        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 \u2014 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.<\/p>\n\n\n\n

        3. Penalty Rules<\/strong><\/p>\n\n\n\n

        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.<\/p>\n\n\n\n

        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 \u2014 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.<\/p>\n\n\n\n

        4. Configuration and Compatibility Rules<\/strong><\/p>\n\n\n\n

        Configuration rules govern product and attribute behaviour during a cart or configuration session \u2014 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.<\/p>\n\n\n\n

        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 \u2014 preventing technically invalid combinations without requiring agents to memorise compatibility matrices.<\/p>\n\n\n\n

        5. Pricing Rules<\/strong><\/p>\n\n\n\n

        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).<\/p>\n\n\n\n

        6. Rules Framework: Context Rules vs Advanced Rules<\/strong><\/p>\n\n\n\n

        EPC provides two implementation pathways for business rules. Context Rules are the recommended default \u2014 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.<\/p>\n\n\n\n

        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 \u2014 teams typically use Context Rules wherever they suffice and reach for Advanced Rules only where the complexity genuinely demands it.<\/p>\n\n\n\n

        Best Practice: Start with Context Rules, Graduate to Advanced<\/strong><\/h3>\n\n\n\n

        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 \u2014 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.<\/p>\n\n\n\n

        7. Decomposition Rules<\/strong><\/p>\n\n\n\n

        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 \u2014 translating what a customer bought into what the network or operations team actually provisions.<\/p>\n\n\n\n

        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 \u2014 for example, routing installation orders through a different fulfillment path than upgrade orders for the same product.<\/p>\n\n\n\n

        Understanding PCM: Components in Detail<\/strong><\/h3>\n\n\n\n

        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 \u2014 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.<\/p>\n\n\n\n

        It is worth clarifying one point: PCM functions as the central product repository for the Revenue Management stack \u2014 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.<\/p>\n\n\n\n

        PCM Architecture: Native Salesforce Stack<\/strong><\/h3>\n\n\n\n
          \n
        • Agentforce \/ Einstein \/ Data Cloud: <\/strong>AI recommendations \u00b7 Autonomous quoting \u00b7 Predictive pricing<\/li>\n<\/ul>\n\n\n\n
            \n
          • Transaction Management + Order Management: <\/strong>Quoting \u00b7 Ordering \u00b7 Fulfillment orchestration<\/li>\n<\/ul>\n\n\n\n
              \n
            • Salesforce Pricing Engine: <\/strong>Price Books \u00b7 Pricing Adjustments \u00b7 Selling Models<\/li>\n<\/ul>\n\n\n\n
                \n
              • Product Catalog Management (PCM): <\/strong>Products \u00b7 Classifications \u00b7 Dynamic Attributes \u00b7 Catalogs \u00b7 Qualification Rules<\/li>\n<\/ul>\n\n\n\n
                  \n
                • Salesforce Core Platform: <\/strong>Native objects \u00b7 Flow \u00b7 Apex \u00b7 SOQL \u00b7 Data Cloud integration<\/li>\n<\/ul>\n\n\n\n

                  1. Product Catalog<\/strong><\/p>\n\n\n\n

                  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 \u2014 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.<\/p>\n\n\n\n

                  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.<\/p>\n\n\n\n

                  2. Dynamic Attributes<\/strong><\/p>\n\n\n\n

                  Dynamic Attributes are PCM’s mechanism for extending product definitions beyond the base Product2 field set \u2014 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.<\/p>\n\n\n\n

                  Attributes are grouped into Attribute Categories, serving the same organisational purpose as their EPC counterparts. Attributes can be defined as configurable \u2014 the customer or agent selects a value during purchase \u2014 or fixed, with the value set at the product level and not adjustable at runtime.<\/p>\n\n\n\n

                  3. Product Classification<\/strong><\/p>\n\n\n\n

                  Product Classifications are PCM’s equivalent of EPC’s Object Types \u2014 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 \u2014 each inheriting the full attribute set automatically.<\/p>\n\n\n\n

                  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 \u2014 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.<\/p>\n\n\n\n

                  Classification Hierarchy \u2192 Product Inheritance<\/strong><\/h3>\n\n\n\n

                  Digital_Service (Parent Classification)  \u2192  inherits  \u2192  Streaming_Service (Child Classification)<\/p>\n\n\n\n

                  Attributes: Billing Frequency, Territory  \u2192  adds  \u2192  + Resolution, Screens, Offline Downloads<\/p>\n\n\n\n

                  Streaming_Service Classification  \u2192  creates  \u2192  Products: StreamBasic \/ StreamStandard \/ StreamPremium<\/p>\n\n\n\n

                  4. Products<\/strong><\/p>\n\n\n\n

                  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.<\/p>\n\n\n\n

                  A Simple product is a standalone item with no hierarchy and no configurable options \u2014 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 \u2014 child product selection within a bundle, attribute value specification, or quantity adjustment within cardinality limits.<\/p>\n\n\n\n

                  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.<\/p>\n\n\n\n

                  5. Qualification Rules<\/strong><\/p>\n\n\n\n

                  PCM Qualification Rules control which products are visible to which customers in which contexts \u2014 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.<\/p>\n\n\n\n

                  Rules can be applied at the product level or at the category level, and they evaluate conditions drawn from any accessible Salesforce data \u2014 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 \u2014 without separate catalog instances per segment.<\/p>\n\n\n\n

                  6. Product List and Product Detail Pages<\/strong><\/p>\n\n\n\n

                  PCM provides two dedicated UI surfaces built into the Revenue Management experience. The Product List page presents the catalog hierarchy \u2014 categories, subcategories, and products within them \u2014 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.<\/p>\n\n\n\n

                  With both platforms mapped at the component level, the logical next step is to see how they translate to each other in practice \u2014 and what that translation means for a real catalog.<\/p>\n\n\n\n

                  EPC vs. PCM: Side-by-Side<\/strong><\/h3>\n\n\n\n

                  Deployment<\/strong><\/p>\n\n\n\n

                  EPC (Enterprise Product Catalog): <\/strong>Managed Package \u2014 Vlocity\/Industries<\/p>\n\n\n\n

                  PCM (Product Catalog Management): <\/strong>Native Salesforce \u2014 no package required<\/p>\n\n\n\n

                  Core Constructs<\/strong><\/p>\n\n\n\n

                  EPC (Enterprise Product Catalog): <\/strong>Spec, Object Type, Picklist, Attribute, Offer<\/p>\n\n\n\n

                  PCM (Product Catalog Management): <\/strong>Product Classification, Dynamic Attributes, Product<\/p>\n\n\n\n

                  UI Surface<\/strong><\/p>\n\n\n\n

                  EPC (Enterprise Product Catalog): <\/strong>Product Designer (LWC) + Product Console (Angular)<\/p>\n\n\n\n

                  PCM (Product Catalog Management): <\/strong>Revenue Management setup pages in core Salesforce<\/p>\n\n\n\n

                  OmniStudio<\/strong><\/p>\n\n\n\n

                  EPC (Enterprise Product Catalog): <\/strong>Tightly coupled \u2014 essential for CPQ Cart & config flows<\/p>\n\n\n\n

                  PCM (Product Catalog Management): <\/strong>Compatible \u2014 but not the only integration option<\/p>\n\n\n\n

                  Industry Scope<\/strong><\/p>\n\n\n\n

                  EPC (Enterprise Product Catalog): <\/strong>Communications, Energy & Utilities, Media<\/p>\n\n\n\n

                  PCM (Product Catalog Management): <\/strong>All Salesforce Industry Clouds + core commercial use cases<\/p>\n\n\n\n

                  Pricing<\/strong><\/p>\n\n\n\n

                  EPC (Enterprise Product Catalog): <\/strong>Price Lists, Pricing Components, Matrix Pricing, Pricing Plan<\/p>\n\n\n\n

                  PCM (Product Catalog Management): <\/strong>Salesforce Pricing engine with native Pricing Adjustments<\/p>\n\n\n\n

                  Rules Engine<\/strong><\/p>\n\n\n\n

                  EPC (Enterprise Product Catalog): <\/strong>Cardinality, Qualification, Penalty, Config, Decomposition<\/p>\n\n\n\n

                  PCM (Product Catalog Management): <\/strong>Qualification Rules, Selling Models, Order Terms<\/p>\n\n\n\n

                  Fulfillment<\/strong><\/p>\n\n\n\n

                  EPC (Enterprise Product Catalog): <\/strong>Decomposition Rules \u2192 Vlocity Order Management<\/p>\n\n\n\n

                  PCM (Product Catalog Management): <\/strong>Order orchestration via native Salesforce Order Management<\/p>\n\n\n\n

                  Release Cadence<\/strong><\/p>\n\n\n\n

                  EPC (Enterprise Product Catalog): <\/strong>Managed package cycle \u2014 independent of core releases<\/p>\n\n\n\n

                  PCM (Product Catalog Management): <\/strong>Standard Salesforce tri-annual release cycle<\/p>\n\n\n\n

                  AI Readiness<\/strong><\/p>\n\n\n\n

                  EPC (Enterprise Product Catalog): <\/strong>Requires custom API bridge to Data Cloud<\/p>\n\n\n\n

                  PCM (Product Catalog Management): <\/strong>Native Data Cloud + Einstein integration out of the box<\/p>\n\n\n\n

                  Real-World Migration Example: A Fibre Broadband Portfolio<\/strong><\/h3>\n\n\n\n

                  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.<\/p>\n\n\n\n

                  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 \u2014 including the decisions, trade-offs, and surprises they encountered along the way.<\/p>\n\n\n\n

                  How the Catalog Was Built in EPC<\/strong><\/h3>\n\n\n\n

                  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.<\/p>\n\n\n\n

                  Three Product Specs \u2014 FTTP_100Mbps, FTTP_300Mbps, FTTP_1Gbps \u2014 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.<\/p>\n\n\n\n

                  EPC Configuration Summary \u2014 FibreHome Portfolio<\/strong><\/h3>\n\n\n\n

                  Object Type: Fibre_Residential<\/p>\n\n\n\n

                  Attributes: Download_Speed, Contract_Term, Router_Model<\/p>\n\n\n\n

                  Specs: FTTP_100Mbps, FTTP_300Mbps, FTTP_1Gbps<\/p>\n\n\n\n

                  Offers: 6 total (3 speeds \u00d7 2 contract terms)<\/p>\n\n\n\n

                  Price List: Residential_PL \u2192 B2C Price Book<\/p>\n\n\n\n

                  Pricing: AED 149\u2013249\/mo recurring + AED 99 one-time<\/p>\n\n\n\n

                  Matrix Pricing: Speed-tier attribute matrix<\/p>\n\n\n\n

                  Pricing Rule: 15% off for 24-month term<\/p>\n\n\n\n

                  Qualification: Account_Type = Residential<\/p>\n\n\n\n

                  Penalty: 50% early exit on 24-month contracts<\/p>\n\n\n\n

                  Decomposition: Provision_FTTP_Access + Activate_ONT_Device per offer<\/p>\n\n\n\n

                  The Full Component Migration Mapping<\/strong><\/h3>\n\n\n\n

                  The table below maps every EPC component in the FibreHome catalog to its PCM counterpart, with specific migration actions for each:<\/p>\n\n\n\n

                  Picklist<\/strong><\/h3>\n\n\n\n

                  Telco Example in EPC: <\/strong>SIM_Type: Physical, eSIM, Dual-SIM<\/p>\n\n\n\n

                  PCM Equivalent: <\/strong>Dynamic Attribute \u2014 value set on Classification<\/p>\n\n\n\n

                  Migration Note: <\/strong>Values recreated as attribute options in PCM<\/p>\n\n\n\n

                  Attribute Category<\/strong><\/p>\n\n\n\n

                  Telco Example in EPC: <\/strong>‘Network Settings’ grouping Speed & Technology<\/p>\n\n\n\n

                  PCM Equivalent: <\/strong>Attribute Category on Product Classification<\/p>\n\n\n\n

                  Migration Note: <\/strong>Category structure preserved; mapped 1:1<\/p>\n\n\n\n

                  Product Attribute<\/strong><\/h3>\n\n\n\n

                  Telco Example in EPC: <\/strong>Download_Speed: 100Mbps, 300Mbps, 1Gbps<\/p>\n\n\n\n

                  PCM Equivalent: <\/strong>Dynamic Attribute on ‘Broadband’ Classification<\/p>\n\n\n\n

                  Migration Note: <\/strong>Inherited by all Broadband products automatically<\/p>\n\n\n\n

                  Object Type<\/strong><\/h3>\n\n\n\n

                  Telco Example in EPC: <\/strong>Fibre_Residential \u2014 shared by all FTTP products<\/p>\n\n\n\n

                  PCM Equivalent: <\/strong>Product Classification: Fibre_Residential<\/p>\n\n\n\n

                  Migration Note: <\/strong>Classification hierarchy replaces OT inheritance<\/p>\n\n\n\n

                  Object Type Layout<\/strong><\/h3>\n\n\n\n

                  Telco Example in EPC: <\/strong>2-column layout: Network tab, Commercial tab<\/p>\n\n\n\n

                  PCM Equivalent: <\/strong>Attribute groupings on Classification record<\/p>\n\n\n\n

                  Migration Note: <\/strong>Recreated using PCM attribute category ordering<\/p>\n\n\n\n

                  Product Spec<\/strong><\/h3>\n\n\n\n

                  Telco Example in EPC: <\/strong>FTTP_100Mbps \u2014 blueprint, not yet sellable<\/p>\n\n\n\n

                  PCM Equivalent: <\/strong>Product record linked to Fibre_Residential Classification<\/p>\n\n\n\n

                  Migration Note: <\/strong>Product2 record with Classification reference<\/p>\n\n\n\n

                  Product Offer<\/strong><\/h3>\n\n\n\n

                  Telco Example in EPC: <\/strong>FibreHome_100_AED149 \u2014 sellable with pricing<\/p>\n\n\n\n

                  PCM Equivalent: <\/strong>Product with Price Book Entry + Selling Model<\/p>\n\n\n\n

                  Migration Note: <\/strong>Selling model set to term-defined, 12\/24 months<\/p>\n\n\n\n

                  Price List<\/strong><\/h3>\n\n\n\n

                  Telco Example in EPC: <\/strong>Residential_PL linked to B2C Price Book<\/p>\n\n\n\n

                  PCM Equivalent: <\/strong>Price Book \u2014 Residential with channel context rule<\/p>\n\n\n\n

                  Migration Note: <\/strong>Context rule rebuilt using PCM qualification<\/p>\n\n\n\n

                  Pricing Component<\/strong><\/h3>\n\n\n\n

                  Telco Example in EPC: <\/strong>Recurring: AED 149\/mo + One-time install: AED 99<\/p>\n\n\n\n

                  PCM Equivalent: <\/strong>Price Book Entries \u2014 recurring + one-time charges<\/p>\n\n\n\n

                  Migration Note: <\/strong>Two separate PBEs per product in PCM<\/p>\n\n\n\n

                  Matrix Pricing<\/strong><\/h3>\n\n\n\n

                  Telco Example in EPC: <\/strong>Speed tier pricing: 100Mbps=AED149, 1Gbps=AED249<\/p>\n\n\n\n

                  PCM Equivalent: <\/strong>Attribute-based Pricing Adjustment in RCA Pricing<\/p>\n\n\n\n

                  Migration Note: <\/strong>Rule triggers on Download_Speed attribute value<\/p>\n\n\n\n

                  Pricing Plan<\/strong><\/h3>\n\n\n\n

                  Telco Example in EPC: <\/strong>Custom step: 3rd party credit-check pricing API<\/p>\n\n\n\n

                  PCM Equivalent: <\/strong>Pricing Procedure with custom Flow step<\/p>\n\n\n\n

                  Migration Note: <\/strong>Flow action replaces Apex-based custom step<\/p>\n\n\n\n

                  Cardinality Rule<\/strong><\/h3>\n\n\n\n

                  Telco Example in EPC: <\/strong>Min 1, Max 3 add-ons per Fibre bundle<\/p>\n\n\n\n

                  PCM Equivalent: <\/strong>Product Bundle child configuration \u2014 min\/max qty<\/p>\n\n\n\n

                  Migration Note: <\/strong>Configured at bundle product level in PCM<\/p>\n\n\n\n

                  Qualification Rule<\/strong><\/h3>\n\n\n\n

                  Telco Example in EPC: <\/strong>FibreHome offer: only for residential accounts<\/p>\n\n\n\n

                  PCM Equivalent: <\/strong>PCM Qualification Rule on Product<\/p>\n\n\n\n

                  Migration Note: <\/strong>Condition: Account Type = Residential<\/p>\n\n\n\n

                  Penalty Rule<\/strong><\/h3>\n\n\n\n

                  Telco Example in EPC: <\/strong>Early exit: recover 50% of remaining contract value<\/p>\n\n\n\n

                  PCM Equivalent: <\/strong>Penalty logic via Order Contract Terms<\/p>\n\n\n\n

                  Migration Note: <\/strong>Mapped to commitment period in native OM<\/p>\n\n\n\n

                  Config\/Compat Rule<\/strong><\/h3>\n\n\n\n

                  Telco Example in EPC: <\/strong>If Router_Type = WiFi6, then WiFi5 is excluded<\/p>\n\n\n\n

                  PCM Equivalent: <\/strong>Attribute dependency rule on Product Classification<\/p>\n\n\n\n

                  Migration Note: <\/strong>Rebuilt using PCM attribute visibility rules<\/p>\n\n\n\n

                  Pricing Rule<\/strong><\/h3>\n\n\n\n

                  Telco Example in EPC: <\/strong>15% off if contract term = 24 months<\/p>\n\n\n\n

                  PCM Equivalent: <\/strong>Pricing Adjustment Rule in RCA Pricing engine<\/p>\n\n\n\n

                  Migration Note: <\/strong>Triggered by Selling Model term selection<\/p>\n\n\n\n

                  Decomposition Rule<\/strong><\/h3>\n\n\n\n

                  Telco Example in EPC: <\/strong>FibreHome \u2192 Provision_FTTP + Activate_Router tasks<\/p>\n\n\n\n

                  PCM Equivalent: <\/strong>Order Orchestration Flow in native Salesforce OM<\/p>\n\n\n\n

                  Migration Note: <\/strong>Fulfillment steps mapped to OM orchestration<\/p>\n\n\n\n

                  What the Migration Team Actually Did<\/strong><\/h3>\n\n\n\n

                  The project began with a full Bulk API export of all FibreHome catalog data \u2014 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.<\/p>\n\n\n\n

                  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 \u2014 one for the recurring monthly charge and one for the one-time installation fee \u2014 since PCM does not use a composite Pricing Component object.<\/p>\n\n\n\n

                  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 \u2014 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.<\/p>\n\n\n\n

                  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 \u2014 it could not be done by the catalog team alone.<\/p>\n\n\n\n

                  Best Practice: Validate Pricing Before Anything Else Goes to UAT<\/strong><\/h3>\n\n\n\n

                  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 \u2014 not during it.<\/p>\n\n\n\n

                  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.<\/p>\n\n\n\n

                  The Business Case for Migration<\/strong><\/h3>\n\n\n\n

                  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 \u2014 it is \u2014 but whether the cost of not migrating is higher. For most organisations on EPC, the calculus has shifted decisively toward migration.<\/p>\n\n\n\n

                  Staying on the Platform Roadmap<\/strong><\/h3>\n\n\n\n

                  Salesforce’s strategic investment in the commercial stack flows into PCM, Salesforce Pricing, and Agentforce Revenue Management \u2014 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.<\/p>\n\n\n\n

                  Reducing Package Dependency Overhead<\/strong><\/h3>\n\n\n\n

                  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 \u2014 no package upgrade scheduling required.<\/p>\n\n\n\n

                  A Single Commercial Data Model<\/strong><\/h3>\n\n\n\n

                  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.<\/p>\n\n\n\n

                  AI and Agentforce Readiness<\/strong><\/h3>\n\n\n\n

                  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 \u2014 and they are only accessible through a native catalog foundation.<\/p>\n\n\n\n

                  Challenges and Best Practices<\/strong><\/h3>\n\n\n\n

                  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 \u2014 and the best practices are grounded in what actually works, not what the project plan assumed would work.<\/p>\n\n\n\n

                  Challenge: OmniScript and Integration Procedure Rework<\/strong><\/h3>\n\n\n\n

                  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 \u2014 not as a downstream task to be addressed after catalog migration is complete.<\/p>\n\n\n\n

                  Challenge: Pricing Model Translation<\/strong><\/h3>\n\n\n\n

                  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 \u2014 ‘the price is AED X when condition Y is true, adjusted by Z% when condition W is also true’ \u2014 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.<\/p>\n\n\n\n

                  Challenge: Decomposition Rule Migration<\/strong><\/h3>\n\n\n\n

                  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 \u2014 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.<\/p>\n\n\n\n

                  Best Practice: Component-Level Audit Before Anything Else<\/strong><\/h3>\n\n\n\n

                  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.<\/p>\n\n\n\n

                  Best Practice: Migrate by Product Domain in Phases<\/strong><\/h3>\n\n\n\n

                  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 \u2014 starting with one product line, validating it fully in production, then proceeding \u2014 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.<\/p>\n\n\n\n

                  Best Practice: Define a Clear ‘Done’ Criteria Before Starting<\/strong><\/h3>\n\n\n\n

                  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.<\/p>\n\n\n\n

                  Conclusion: The Platform Is Ready. Is Your Catalog?<\/strong><\/h3>\n\n\n\n

                  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 \u2014 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.<\/p>\n\n\n\n

                  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 \u2014 native platform objects, tri-annual release cadence, direct AI integration, no package boundary between the catalog and the commercial stack.<\/p>\n\n\n\n

                  The strategic argument for migration has become more straightforward with every Salesforce release. Each release adds new capabilities \u2014 Agentforce product agents, Data Cloud product unification, Einstein pricing models \u2014 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.<\/p>\n\n\n\n

                  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 \u2014 it is where the time goes.<\/p>\n\n\n\n

                  The platform is ready. Organisations that complete this migration will find themselves operating on a commercial foundation that grows more capable with every release \u2014 without a single managed package upgrade cycle standing between them and what is next.<\/p>\n","protected":false},"excerpt":{"rendered":"

                  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 \u2014 surface the right product to the right customer, generate […]<\/p>\n","protected":false},"author":1,"featured_media":68,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-54","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-salesforce"],"_links":{"self":[{"href":"https:\/\/www.encoderapps.com\/blog\/wp-json\/wp\/v2\/posts\/54","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.encoderapps.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.encoderapps.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.encoderapps.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.encoderapps.com\/blog\/wp-json\/wp\/v2\/comments?post=54"}],"version-history":[{"count":7,"href":"https:\/\/www.encoderapps.com\/blog\/wp-json\/wp\/v2\/posts\/54\/revisions"}],"predecessor-version":[{"id":79,"href":"https:\/\/www.encoderapps.com\/blog\/wp-json\/wp\/v2\/posts\/54\/revisions\/79"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.encoderapps.com\/blog\/wp-json\/wp\/v2\/media\/68"}],"wp:attachment":[{"href":"https:\/\/www.encoderapps.com\/blog\/wp-json\/wp\/v2\/media?parent=54"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.encoderapps.com\/blog\/wp-json\/wp\/v2\/categories?post=54"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.encoderapps.com\/blog\/wp-json\/wp\/v2\/tags?post=54"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}