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