{"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-06-23T06:03:50","modified_gmt":"2026-06-23T06:03:50","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":"Leaving the Package Behind How to Migrate from Salesforce EPC to Product Catalog Management \u2014 and Why It"},"content":{"rendered":"\n

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

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

Introduction<\/strong><\/h2>\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.
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.
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.
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>
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.
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

Architecture Insight: Who This Guide Is For<\/strong>
This article is written for Salesforce architects and senior consultants who know EPC well and
want to understand PCM at the same depth. Business stakeholders will find the Business Case
and Migration sections most relevant. Developers will find the component mapping table and
migration walkthrough most useful.<\/p>\n\n\n\n

EPC Architecture: Three Functional Layers<\/strong><\/p>\n\n\n\n

Business Rules Layer
Cardinality \u00b7 Qualification \u00b7 Penalty \u00b7 Configuration \u00b7 Pricing Rules \u00b7 Decomposition
Pricing Configuration Layer
Price Lists \u00b7 Pricing Components \u00b7 Promotions \u00b7 Discounts \u00b7 Matrix Pricing \u00b7 Pricing Plan
Product Design Layer
Picklists \u00b7 Attribute Categories \u00b7 Attributes \u00b7 Object Types \u00b7 Layouts \u00b7 Specs \u00b7 Offers<\/p>\n\n\n\n

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

Product Designer<\/strong>
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>
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.
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
    \n
  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 \u2014 distinct from<\/li>\n<\/ol>\n\n\n\n

    standard Salesforce picklist fields \u2014 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.<\/p>\n\n\n\n

    Architecture Insight: Picklists vs Standard Salesforce Picklists<\/strong>
    EPC Picklists are entirely separate from standard Salesforce picklist fields. They live in the
    Vlocity namespace, store their values as child records rather than field metadata, and are
    read\/written through Industries CPQ tooling. This distinction matters significantly during
    migration \u2014 PCM Dynamic Attributes use a different value storage model that must be
    accounted for in the transformation script.<\/p>\n\n\n\n

      \n
    1. Attribute Category<\/strong>
      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 \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.
      <\/li>\n\n\n\n
    2. Product Attribute<\/strong>
      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.
      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.<\/li>\n<\/ol>\n\n\n\n

      Architecture Insight: Why Attributes Live in JSON<\/strong>
      Storing attributes as JSON on Product2 was a deliberate design choice that gave EPC near-
      unlimited flexibility at the cost of queryability. During migration to PCM, this JSON payload must
      be parsed and mapped to individual Dynamic Attribute records \u2014 a step that requires careful
      transformation logic, especially for attributes that contain nested or conditional values.<\/p>\n\n\n\n

        \n
      1. Product Object Type<\/strong>
        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.
        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.<\/li>\n<\/ol>\n\n\n\n

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

        Residential_Access (Parent OT) inherits \u2193 FTTP_Residential (Child OT)
        Attributes: Address, Contract
        Term, Start Date<\/p>\n\n\n\n

        adds \u2193 + Download Speed, Router
        Model, Technology Type
        FTTP_Residential OT creates \u2193 Product Spec: FTTP_100Mbps<\/p>\n\n\n\n

          \n
        1. Object Type Layout<\/strong>
          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.
          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.<\/li>\n\n\n\n
        2. Product Specification<\/strong>
          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.
          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.<\/li>\n<\/ol>\n\n\n\n

          Architecture Insight: Spec vs Offer: A Critical Distinction<\/strong>
          One of the most common misunderstandings in EPC implementations is conflating the Product<\/p>\n\n\n\n

          Spec with the sellable Product Offer. A Spec defines what a product IS. An Offer defines how it
          is SOLD \u2014 with price, catalog assignment, and business rules attached. A single Spec can
          generate many Offers, each with different commercial terms. This distinction maps directly to
          PCM: the Product record (equivalent to Spec) and Price Book Entry + Selling Model (equivalent
          to Offer’s commercial layer) are separate constructs.<\/p>\n\n\n\n

            \n
          1. Product Offer<\/strong>
            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.
            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
            <\/li>\n\n\n\n
          2. Pricing Components<\/strong>
            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.
            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.<\/li>\n<\/ol>\n\n\n\n

            Architecture Insight: Pricing Components vs Price Book Entries in PCM<\/h3>\n\n\n\n

            EPC assembles a product’s total price from multiple Pricing Component records. PCM uses
            separate Price Book Entries for each charge type \u2014 one entry for recurring charges, another for
            one-time fees. The migration transformation must split EPC’s component records into individual
            PCM Price Book Entries, preserving charge type classification to ensure correct billing behaviour
            downstream.<\/p>\n\n\n\n

              \n
            1. Price List<\/strong>
              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.<\/li>\n<\/ol>\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

                \n
              1. Cost and Margin<\/strong>
                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.
                <\/li>\n\n\n\n
              2. Promotion<\/strong>
                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.
                <\/li>\n\n\n\n
              3. Discount<\/strong>
                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.
                <\/li>\n\n\n\n
              4. Attribute-Based Pricing (Matrix Pricing)<\/strong>
                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.<\/li>\n<\/ol>\n\n\n\n

                Best Practice: When to Use Matrix Pricing vs Separate Offers<\/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

                  \n
                1. Pricing Plan<\/strong>
                  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.
                  Business Rules Components
                  <\/li>\n\n\n\n
                2. Cardinality Rules<\/strong>
                  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.
                  <\/li>\n\n\n\n
                3. Qualification Rules<\/strong>
                  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.
                  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.<\/li>\n<\/ol>\n\n\n\n

                  Best Practice: Qualification Rules vs Multiple Catalogs<\/strong>
                  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

                    \n
                  1. 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 \u2014 a 30% discount offered in exchange for a 24-month<\/li>\n<\/ol>\n\n\n\n

                    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

                      \n
                    1. Configuration and Compatibility Rules<\/strong>
                      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.
                      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.<\/li>\n<\/ol>\n\n\n\n

                      Common Migration Mistake: Overbuilding Configuration Rules
                      One of the most common EPC implementation mistakes is encoding every possible product
                      compatibility constraint as a configuration rule \u2014 including constraints that rarely or never trigger
                      in real quotes. Each active configuration rule adds evaluation overhead to every cart interaction.
                      Audit your rules regularly and retire those that exist to handle theoretical edge cases rather than
                      real customer scenarios.<\/p>\n\n\n\n

                        \n
                      1. Pricing Rules<\/strong>
                        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).
                        <\/li>\n\n\n\n
                      2. Rules Framework: Context Rules vs Advanced Rules<\/strong>
                        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.
                        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.<\/li>\n<\/ol>\n\n\n\n

                        Best Practice: Start with Context Rules, Graduate to Advanced<\/strong>
                        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<\/p>\n\n\n\n

                        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

                          \n
                        1. Decomposition Rules<\/strong>
                          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.
                          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.<\/li>\n<\/ol>\n\n\n\n

                          Architecture Insight: Decomposition Rules: The Most Underestimated Migration
                          Component<\/strong>
                          Teams often focus migration planning on product specs, offers, and pricing \u2014 and treat
                          decomposition rules as a downstream concern. This is a planning mistake. Decomposition rules
                          touch both the catalog team (who owns the commercial product) and the Order Management
                          team (who owns fulfillment). In PCM, this responsibility shifts to native Salesforce Order
                          Orchestration Flows \u2014 an architectural change that requires both teams to be engaged from the
                          start of the migration project.<\/p>\n\n\n\n

                          Understanding PCM: Components in Detail<\/strong>
                          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.
                          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><\/p>\n\n\n\n

                          Agentforce \/ Einstein \/ Data Cloud<\/strong><\/p>\n\n\n\n

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

                            \n
                          1. Product Catalog<\/strong>
                            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.
                            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.<\/li>\n<\/ol>\n\n\n\n

                            Architecture Insight: PCM Catalogs Are Flatter by Design<\/strong>
                            EPC’s hierarchical catalog structure gave operators deep nesting capability \u2014 parent catalogs
                            containing child catalogs containing sub-catalogs. PCM’s flatter model with explicit assignments
                            is intentional: it trades nesting depth for administrative clarity. Teams migrating from deep EPC
                            catalog hierarchies should map their structure to PCM’s explicit assignment model early in the
                            planning phase, as it may require rethinking how product scoping is organised.<\/p>\n\n\n\n

                              \n
                            1. Dynamic Attributes<\/strong>
                              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.
                              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.<\/li>\n\n\n\n
                            2. Product Classification<\/strong>
                              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.
                              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.<\/li>\n<\/ol>\n\n\n\n

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

                              Digital_Service (Parent
                              Classification)<\/p>\n\n\n\n

                              inherits \u2193 Streaming_Service (Child
                              Classification)<\/p>\n\n\n\n

                              Attributes: Billing Frequency,<\/p>\n\n\n\n

                              Territory<\/strong><\/p>\n\n\n\n

                              adds \u2193 + Resolution, Screens, Offline
                              Downloads
                              Streaming_Service Classification creates \u2193 Products: StreamBasic \/
                              StreamStandard \/
                              StreamPremium<\/p>\n\n\n\n

                                \n
                              1. Products<\/strong>
                                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 \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.
                                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.<\/li>\n\n\n\n
                              2. Qualification Rules<\/strong>
                                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.<\/li>\n<\/ol>\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

                                  \n
                                1. Product List and Product Detail Pages<\/strong>
                                  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.<\/li>\n<\/ol>\n\n\n\n

                                  Architecture Insight: OmniStudio Is Still Relevant in PCM<\/strong>
                                  PCM provides native browsing UI, but most enterprise buying and quoting experiences will still
                                  use OmniStudio \u2014 particularly for complex guided selling flows, multi-step configuration, and
                                  B2B quote-building journeys. The difference is that OmniStudio in a PCM context calls native
                                  Salesforce APIs rather than EPC-specific endpoints, making the integration layer simpler to build
                                  and maintain.<\/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><\/p>\n\n\n\n

                                  Dimension EPC (Enterprise Product Catalog) PCM (Product Catalog
                                  Management)<\/p>\n\n\n\n

                                  Deployment Managed Package \u2014
                                  Vlocity\/Industries<\/p>\n\n\n\n

                                  Native Salesforce \u2014 no package
                                  required<\/p>\n\n\n\n

                                  Core Constructs Spec, Object Type, Picklist,<\/p>\n\n\n\n

                                  Attribute, Offer<\/p>\n\n\n\n

                                  Product Classification, Dynamic
                                  Attributes, Product<\/p>\n\n\n\n

                                  UI Surface Product Designer (LWC) + Product<\/p>\n\n\n\n

                                  Console (Angular)<\/p>\n\n\n\n

                                  Revenue Management setup pages
                                  in core Salesforce<\/p>\n\n\n\n

                                  OmniStudio Tightly coupled \u2014 essential for
                                  CPQ Cart & config flows<\/p>\n\n\n\n

                                  Compatible \u2014 but not the only
                                  integration option<\/p>\n\n\n\n

                                  Industry Scope Communications, Energy & Utilities,<\/p>\n\n\n\n

                                  Media<\/p>\n\n\n\n

                                  All Salesforce Industry Clouds +
                                  core commercial use cases<\/p>\n\n\n\n

                                  Pricing Price Lists, Pricing Components,
                                  Matrix Pricing, Pricing Plan<\/p>\n\n\n\n

                                  Salesforce Pricing engine with
                                  native Pricing Adjustments<\/p>\n\n\n\n

                                  Rules Engine Cardinality, Qualification, Penalty,<\/p>\n\n\n\n

                                  Config, Decomposition<\/p>\n\n\n\n

                                  Qualification Rules, Selling Models,
                                  Order Terms<\/p>\n\n\n\n

                                  Fulfillment Decomposition Rules \u2192 Vlocity<\/p>\n\n\n\n

                                  Order Management<\/p>\n\n\n\n

                                  Order orchestration via native
                                  Salesforce Order Management<\/p>\n\n\n\n

                                  Release Cadence Managed package cycle \u2014
                                  independent of core releases<\/p>\n\n\n\n

                                  Standard Salesforce tri-annual
                                  release cycle<\/p>\n\n\n\n

                                  AI Readiness Requires custom API bridge to Data<\/p>\n\n\n\n

                                  Cloud<\/p>\n\n\n\n

                                  Native Data Cloud + Einstein
                                  integration out of the box<\/p>\n\n\n\n

                                  Real-World Migration Example: A Fibre Broadband
                                  Portfolio<\/strong>
                                  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 \u2014 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 \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<\/p>\n\n\n\n

                                  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>
                                  Object Type: Fibre_Residential | Attributes: Download_Speed, Contract_Term, Router_Model |
                                  Specs: FTTP_100Mbps, FTTP_300Mbps, FTTP_1Gbps | Offers: 6 total (3 speeds \u00d7 2 contract
                                  terms) | Price List: Residential_PL \u2192 B2C Price Book | Pricing: AED 149\u2013249\/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<\/p>\n\n\n\n

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

                                  EPC Construct Telco Example in<\/p>\n\n\n\n

                                  EPC<\/p>\n\n\n\n

                                  PCM Equivalent Migration Note<\/p>\n\n\n\n

                                  Picklist SIM_Type: Physical,
                                  eSIM, Dual-SIM<\/p>\n\n\n\n

                                  Dynamic Attribute \u2014
                                  value set on
                                  Classification<\/p>\n\n\n\n

                                  Values recreated as attribute
                                  options in PCM<\/p>\n\n\n\n

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

                                  ‘Network Settings’
                                  grouping Speed &
                                  Technology<\/p>\n\n\n\n

                                  Attribute Category on
                                  Product Classification<\/p>\n\n\n\n

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

                                  Product Attribute Download_Speed:
                                  100Mbps, 300Mbps,
                                  1Gbps<\/p>\n\n\n\n

                                  Dynamic Attribute on
                                  ‘Broadband’
                                  Classification<\/p>\n\n\n\n

                                  Inherited by all Broadband
                                  products automatically<\/p>\n\n\n\n

                                  Object Type Fibre_Residential \u2014
                                  shared by all FTTP
                                  products<\/p>\n\n\n\n

                                  Product Classification:
                                  Fibre_Residential<\/p>\n\n\n\n

                                  Classification hierarchy replaces
                                  OT inheritance<\/p>\n\n\n\n

                                  Object Type
                                  Layout<\/p>\n\n\n\n

                                  2-column layout:
                                  Network tab,
                                  Commercial tab<\/p>\n\n\n\n

                                  Attribute groupings on
                                  Classification record<\/p>\n\n\n\n

                                  Recreated using PCM attribute
                                  category ordering<\/p>\n\n\n\n

                                  Product Spec FTTP_100Mbps \u2014
                                  blueprint, not yet
                                  sellable<\/p>\n\n\n\n

                                  Product record linked
                                  to Fibre_Residential
                                  Classification<\/p>\n\n\n\n

                                  Product2 record with Classification
                                  reference<\/p>\n\n\n\n

                                  Product Offer FibreHome_100_AED
                                  149 \u2014 sellable with
                                  pricing<\/p>\n\n\n\n

                                  Product with Price
                                  Book Entry + Selling
                                  Model<\/p>\n\n\n\n

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

                                  Price List Residential_PL linked
                                  to B2C Price Book<\/p>\n\n\n\n

                                  Price Book \u2014
                                  Residential with
                                  channel context rule<\/p>\n\n\n\n

                                  Context rule rebuilt using PCM
                                  qualification<\/p>\n\n\n\n

                                  Pricing
                                  Component<\/p>\n\n\n\n

                                  Recurring: AED
                                  149\/mo + One-time
                                  install: AED 99<\/p>\n\n\n\n

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

                                  Two separate PBEs per product in
                                  PCM<\/p>\n\n\n\n

                                  Matrix Pricing Speed tier pricing:
                                  100Mbps=AED149,
                                  1Gbps=AED249<\/p>\n\n\n\n

                                  Attribute-based
                                  Pricing Adjustment in
                                  RCA Pricing<\/p>\n\n\n\n

                                  Rule triggers on Download_Speed
                                  attribute value<\/p>\n\n\n\n

                                  Pricing Plan Custom step: 3rd
                                  party credit-check
                                  pricing API<\/p>\n\n\n\n

                                  Pricing Procedure with
                                  custom Flow step<\/p>\n\n\n\n

                                  Flow action replaces Apex-based
                                  custom step<\/p>\n\n\n\n

                                  Cardinality Rule Min 1, Max 3 add-ons
                                  per Fibre bundle<\/p>\n\n\n\n

                                  Product Bundle child
                                  configuration \u2014
                                  min\/max qty<\/p>\n\n\n\n

                                  Configured at bundle product level
                                  in PCM<\/p>\n\n\n\n

                                  Qualification Rule FibreHome offer: only
                                  for residential
                                  accounts<\/p>\n\n\n\n

                                  PCM Qualification
                                  Rule on Product<\/p>\n\n\n\n

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

                                  Penalty Rule Early exit: recover
                                  50% of remaining
                                  contract value<\/p>\n\n\n\n

                                  Penalty logic via Order
                                  Contract Terms<\/p>\n\n\n\n

                                  Mapped to commitment period in
                                  native OM<\/p>\n\n\n\n

                                  Config\/Compat
                                  Rule<\/p>\n\n\n\n

                                  If Router_Type =
                                  WiFi6, then WiFi5 is
                                  excluded<\/p>\n\n\n\n

                                  Attribute dependency
                                  rule on Product
                                  Classification<\/p>\n\n\n\n

                                  Rebuilt using PCM attribute
                                  visibility rules<\/p>\n\n\n\n

                                  Pricing Rule 15% off if contract
                                  term = 24 months<\/p>\n\n\n\n

                                  Pricing Adjustment
                                  Rule in RCA Pricing
                                  engine<\/p>\n\n\n\n

                                  Triggered by Selling Model term
                                  selection<\/p>\n\n\n\n

                                  Decomposition
                                  Rule<\/p>\n\n\n\n

                                  FibreHome \u2192
                                  Provision_FTTP +
                                  Activate_Router tasks<\/p>\n\n\n\n

                                  Order Orchestration
                                  Flow in native
                                  Salesforce OM<\/p>\n\n\n\n

                                  Fulfillment steps mapped to OM
                                  orchestration<\/p>\n\n\n\n

                                  Common Migration Mistake: Don’t Migrate Rules Before Products<\/strong>
                                  A common sequencing error is attempting to create Qualification Rules or Pricing Adjustment
                                  Rules in PCM before the products and classifications they reference have been created. PCM’s
                                  rules engine validates references at save time \u2014 orphaned rules will fail silently or throw
                                  validation errors that are time-consuming to diagnose. Always complete the product and
                                  classification layer before building the rules layer.<\/p>\n\n\n\n

                                  What the Migration Team Actually Did<\/strong>
                                  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.
                                  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.
                                  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>
                                  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>
                                  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.
                                  Staying on the Platform Roadmap
                                  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

                                  Architecture Insight: What Gets Harder Every Release You Wait<\/strong>
                                  Each Salesforce release brings new capabilities that assume native product data \u2014 Agentforce
                                  product agents, Einstein recommendation models trained on catalog data, Data Cloud product
                                  unification. Every release you stay on EPC widens the gap between what your catalog can
                                  power and what the platform can deliver. The migration cost is relatively fixed. The opportunity<\/p>\n\n\n\n

                                  cost of staying grows with each release.<\/p>\n\n\n\n

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

                                  Challenges and Best Practices<\/strong>
                                  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.

                                  Challenge: OmniScript and Integration Procedure Rework<\/strong>
                                  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

                                  Common Migration Mistake: Treating OmniStudio Rework as a Low-Effort Task<\/strong>
                                  Teams frequently underestimate OmniStudio rework because individual components look simple
                                  in isolation. The complexity comes from volume and interdependency \u2014 dozens of Integration
                                  Procedures chained together, FlexCards referencing EPC object fields by API name,
                                  OmniScripts with conditional logic branching on EPC-specific values. An audit of all OmniStudio
                                  components referencing EPC objects or APIs should be the first task of the migration project, not
                                  an afterthought.<\/p>\n\n\n\n

                                  Challenge: Pricing Model Translation<\/strong>
                                  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.

                                  Challenge: Decomposition Rule Migration<\/strong>
                                  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.

                                  Best Practice: Component-Level Audit Before Anything Else<\/strong>
                                  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<\/strong>
                                  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>
                                  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>
                                  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.
                                  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.
                                  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.
                                  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.
                                  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\n\n\n

                                  \n
                                  \"\"<\/figure>\n<\/figure>\n\n\n\n

                                  <\/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 anew Agentforce autonomous quoting workflow. The concept is straightforward \u2014 surface theright product to the right customer, generate a quote, […]<\/p>\n","protected":false},"author":1,"featured_media":0,"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","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":1,"href":"https:\/\/www.encoderapps.com\/blog\/wp-json\/wp\/v2\/posts\/54\/revisions"}],"predecessor-version":[{"id":56,"href":"https:\/\/www.encoderapps.com\/blog\/wp-json\/wp\/v2\/posts\/54\/revisions\/56"}],"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}]}}