📗 Lesson 01 — Core Platform Mechanics
🇦🇷 Comuniqa Case Study
Product Catalog
Management (PCM)
A structured, architect-level deep-dive into the PCM module of Agentforce Revenue Management — grounded in Comuniqa's actual product model. Covers catalog design, attribute architecture, product classification, bundle structure, cardinality, selling models, qualification rules, and how it all feeds downstream.
01 Foundation
Foundational Definitions
PCM is the master data layer for everything sold in Agentforce Revenue Management. Before any quote is created, any price is calculated, or any order is fulfilled, the platform reads from the product catalog. Understanding PCM vocabulary is essential for every downstream design decision.
🗂️
Catalog
The top-level container for products. Comuniqa would have at least one catalog (e.g., "B2C Móvil") organized into categories. A catalog has an effective start and end date — it is time-bounded.
📁
Category
A hierarchical grouping within a catalog. Up to 5 levels deep. Categories organize products for browsing in Product Discovery. Comuniqa examples: "Mobile Plans", "Add-On Services", "Partner Content".
📋
Product Classification
A reusable attribute template. Define attributes once on a classification; all products based on it inherit those attributes automatically. Acts as a "product type" template.
🏷️
Attribute Definition
A single characteristic of a product (text, picklist, number, date, checkbox). Examples: "Contract Term", "SIM Format", "Data Allowance". Defined once, reused across many products via classifications.
📦
Simple Product
A standalone product with no child dependencies. Can be static or configurable. Comuniqa examples: SIM Card, Phone Number, MoviMundo Plus+.
🧩
Bundle Product
A group of products sold together as one unit. Contains product groups and child components. Comuniqa example: "Comuniqa Go! (Comuniqa Vida Digital)".
📐
Product Group
Mandatory structural container inside a configurable bundle. Groups organize child components and define cardinality (min/max selection). Comuniqa groups: "Base Mobile Plan", "Value-Added Services".
🔢
Cardinality
Rules defining how many components a user can select from a group (group cardinality) and how many instances of a product they can add (local cardinality).
🔄
Product Selling Model
Defines HOW a product is sold: One Time, Term-Defined (subscription with end date), or Evergreen (subscription until cancelled).
✅
Qualification Rule
A BRE-powered rule that determines whether a product is eligible for sale to a specific customer. Runs BEFORE product selection.
🔍
Product Discovery
The runtime browsing experience — the "Browse Catalogs" flow that sales agents use to find and add products to a quote or order. Reads from PCM, applies qualification rules, shows prices from the Pricing engine.
🎯
Specification Type
Labels products as Commercial (customer-facing) or Technical (internal/fulfillment). Only Commercial products appear in Product Discovery.
How These Concepts Relate
PCM Mental Model — Build Order
Design flows top to bottom: Catalogs → Categories → Attribute Definitions → Attribute Categories → Product Classifications → Products → Bundle Structures → Selling Models → Qualification Rules. Each layer depends on the one above. Attempting to build products before classifications, or bundles before simple products, is the most common design mistake in implementation.
🇦🇷 Comuniqa Vocabulary Mapping
Catalog = "B2C Móvil Argentina" | Categories = "Mobile Plans", "Add-Ons", "Partner Content", "Subscriptions" | Product Classifications = "Mobile Plan Attributes", "Watch Service Attributes", "Streaming Pass Attributes" | Bundle = "Comuniqa Go! (Comuniqa Vida Digital)" | Groups = "Base Mobile Plan", "Value-Added Services", "Partner Value-Added Services", "Subscriptions"
02 Functional Deep Dive
Detailed Functional Explanation
What PCM Does — Conceptually
PCM is not just a product list. It is an operational engine that every downstream Revenue Cloud module reads from. The configurator reads bundle structure. The pricing engine reads product attributes and selling models. The order management engine reads assetization flags and fulfillment decomposition scope. The billing engine reads selling model billing terms. A poorly designed catalog produces cascading errors in every downstream system.
"The Product Catalog is not a static list. It is an operational engine. Every object in Quote to Cash references it."
— Salesforce Revenue Cloud Architecture Documentation
Comuniqa Product Hierarchy
Comuniqa Go! (Comuniqa Vida Digital) — Full Bundle Hierarchy
🧩 Comuniqa Go! (Comuniqa Vida Digital) — Bundle Root Configurable Bundle
├─
📁 Group: Base Mobile Plan Min 1 / Max 1
│ └─
📦 Comuniqa Go! Required · Default
↳ Sub-components: SIM (req), Phone Number (req), Phone Number Portability (opt), Value-Added Services group, Partner VAS group
└─
📁 Group: Subscriptions Min 0 / Max 1
└─
📦 Comuniqa Vida Digital Pass C&C Optional · Not Default
↳ Sub-components: Mi Coto Discount (req), Club Día Discount (req), Additional Benefits group (min 1 / max 2)
How PCM Is Used Across the Revenue Lifecycle
Product Discovery reads PCM to populate Browse Catalogs:
- Agent opens a quote for a Comuniqa customer → clicks "Browse Catalogs"
- PCM catalog "B2C Móvil Argentina" loads. Qualification procedures run: customer age ≤18? Active lines < max? Credit check passed?
- Qualified products appear. Agent selects "Comuniqa Go!" — bundle structure is read from PCM: SIM and Phone Number auto-added (required, default), optional groups displayed
- Agent selects MoviMundo Plus+ from Partner VAS group. Configurator (reading PCM cardinality rules) enforces that MoviMundo Basic+ cannot also be selected
- Pricing engine reads product attribute values (Contract Term = 12 months) and selling model (Term-Defined) to calculate the ARS 51,750 net price
Order activation reads PCM for fulfillment decomposition:
- Order is submitted. DRO (Dynamic Revenue Orchestrator) reads the PCM product records for decomposition scope
- SIM Card: Is Assetizable = true → DRO creates an asset record. Fulfillment task: provision ICCID from inventory system
- Phone Number: Is Assetizable = true → DRO creates an asset. Fulfillment task: allocate number from number management platform
- Comuniqa Go! (bundle root): Is Assetizable = true → creates parent asset. Child assets for each component inherit assetization from root
- Technical products (network provisioning codes, routing IDs) are read from the technical catalog — hidden from the commercial order view
Amendment reads PCM to understand what can change:
- Customer wants to upgrade from MoviMundo Basic+ to MoviMundo Plus+. Agent opens amendment flow
- PCM bundle structure is re-read to understand the current configuration context and valid options
- Cardinality rules confirm: exactly 1 partner VAS can be selected. Removing Basic+ and adding Plus+ is valid
- PCM product record must be ACTIVE for amendments to proceed. Discontinued products block amendment selection
- Selling model on the amended line is re-read to calculate proration for mid-cycle amendment
Agentforce quote agent reads PCM headlessly via API:
- Agent types: "Quote Comuniqa Go! with MoviMundo Plus+ for a youth customer, 12-month contract, eSIM"
- Agentforce calls the Product Details API → reads PCM product record for "Comuniqa Go!", its bundle structure, and valid selling models
- Attribute values are set: SIM Format = "eSIM", Contract Term = "12 Months" — read from PCM attribute definitions and picklist values
- Qualification procedure runs via API: age check passes, credit check passes → Comuniqa Go! is qualified
- PCM caching is critical: the Product Details API uses a cache layer so the agent gets near-instant product data
Comuniqa Attribute Architecture
| Attribute | Product | Type | Category | Who Populates |
|---|---|---|---|---|
| Voice Calls Included | Comuniqa Go! | Text | Descriptive | Catalog admin (static) |
| Contract Term | Comuniqa Go! | Picklist | Configuration | Agent at order time |
| SIM Card Format | SIM Card | Picklist | Configuration | Agent at order time |
| ICCID | SIM Card | Text | Fulfillment-Populated | Inventory system post-activation |
| Phone Number | Phone Number | Text | Fulfillment-Populated | Number management system |
| Sharing Mode | Family Go! Bundle | Picklist | Configuration | Agent (Immediate / Monthly) |
| Watch Device Type | Go! Two | Picklist | Configuration | Agent (Apple / Samsung) |
| Watch IMEI | Go! Two | Text | Fulfillment-Populated | Device pairing system |
| GoogleEmail | YouTube Mundo | Text | Configuration | Customer-provided |
| ActivationStatus | YouTube Mundo / Netflix | Text | Fulfillment-Populated | Partner API callback |
| Port Date | Phone Number Portability | Date | Operational | Portability system |
| Authorization Code | Phone Number Portability | Text | Configuration | Customer provides |
⚠ Critical Design Decision — Commercial vs Technical Attributes
Comuniqa explicitly chose NOT to track internal network port assignments, rating plan codes, or backend integration keys on commercial product records. These live on Technical products. This keeps the commercial catalog clean and prevents sales agents from seeing — or accidentally modifying — provisioning-critical data. This separation must be designed at catalog inception and is extremely difficult to retrofit.
03 Building Blocks Deep Dive
PCM Building Blocks — Setup Sequence & Dependency Chain
PCM has a strict build order. Each layer depends on the one above it. Understanding this dependency chain prevents the most common implementation mistakes.
The PCM Dependency Chain — Always Build in This Order
1. Catalogs → 2. Categories → 3. Attribute Picklists → 4. Attribute Definitions → 5. Attribute Categories → 6. Product Classifications → 7. Simple Products → 8. Bundle Products + Structure → 9. Product Selling Models → 10. Qualification Rules
PCM Build Order
1 · Catalog
No dependencies — must exist first↓
2 · Categories
Requires: Catalog↓
3 · Attribute Picklists
Needed before Attribute Definitions↓
4 · Attribute Definitions
Requires: Picklists (for Picklist types)↓
5 · Attribute Categories
Requires: Attribute Definitions↓
6 · Product Classifications
Requires: Attribute Definitions + Categories↓
7 · Simple Products
Requires: Classification + Category assignment↓
8 · Bundle Products + Structure
Requires: All child Simple Products exist first↓
9 · Product Selling Models
Requires: Products to exist. Unlocks Price Book Entry creation.↓
10 · Qualification Rules
Requires: Extended Context Definition + Decision Tables + Products🗂️ Block 1 — Catalog: The Top-Level Container
What it is: A Catalog is the highest-level organisational container for all products. You must create at least one catalog before creating categories or assigning products.
| Field | Decision | Comuniqa |
|---|---|---|
| Name | Should reflect the business domain or channel | "B2C Móvil Argentina" |
| Catalog Code | Unique code — used in API references | "CQ-B2C-MOB" |
| Type | Sales (products for purchase) or Service Process | Sales |
| Effective Start / End Date | Catalogs are time-bounded. Leave end date blank for open-ended catalogs. | Start: go-live date. End: blank. |
⚠ Design Decision Comuniqa's B2C and B2B catalogs should be separate — different products, pricing, eligibility rules, and agents. Mixing them into one catalog creates governance complexity. Start clean.
📁 Block 2 — Categories: Organising Products for Discovery
What it is: Categories are hierarchical groupings within a catalog. Up to 5 levels deep. A product can be assigned to more than one category.
| Field | Decision | Comuniqa |
|---|---|---|
| Name & Code | Short, clear names. Code used in APIs. | "Mobile Plans", "Add-On Services", "Partner Content", "Subscriptions" |
| Parent Category | Leave blank for top-level. Set for subcategories. | "Streaming Services" as a subcategory under "Add-On Services" |
| Sort Order | Controls display order in Browse Catalogs. Plan before go-live. | Mobile Plans = −1 (shows first), Add-Ons = 0, Partner Content = 1 |
Design Principle Design the category hierarchy from the agent's perspective, not the product manager's.
📐 Block 6 — Product Classifications: Attribute Templates
What it is: A Product Classification is a reusable attribute template. Products based on a classification automatically inherit all its attributes. It is the primary mechanism for assigning attributes to products.
| Field | Decision | Comuniqa |
|---|---|---|
| Name & Code | Name after the product type it represents, not a specific product. | "Mobile Plan Attributes", "Watch Service Attributes", "Streaming Pass Attributes" |
| Status | Draft → Active → Inactive. Design and test in Draft before activating. | All Comuniqa classifications start in Draft; activated only after UAT. |
| Sub-classifications | Up to 3 levels. Sub-classifications inherit all parent attributes automatically. | Parent: "Mobile Plan Attributes" → Sub: "Youth Plan Attributes" (adds Age Verification flag) |
✅ The maintainability payoff When Comuniqa needs to add a "5G Ready" attribute to all mobile plans, updating one classification propagates it instantly to all products using that classification.
🧩 Block 8 — Bundle Products & Structure: Configurable Multi-Product Offerings
What it is: A Bundle Product groups multiple products sold together. In a configurable bundle, agents and customers choose which optional components to include.
| Decision Point | Rule | Comuniqa Application |
|---|---|---|
| Product Groups | Mandatory in configurable bundles. Each group has its own cardinality. | Groups: "SIM", "Phone Number & Portability", "Value-Added Services", "Partner Value-Added Services" |
| Required vs Optional | Required = solid line, must always be included. Optional = dashed line. | SIM = Required + Default. MoviMundo Plus+/Basic+ = Optional, not default. |
| Group Cardinality (Min/Max) | Controls how many distinct child products a customer can select from a group. Max=1 enforces mutual exclusivity. | Partner VAS group: Min=0, Max=1 — only ONE of MoviMundo Basic+, Plus+ can be selected. |
| Local Cardinality | Controls how many instances of a specific component can be added. | Comuniqa Go! Two: Min=0, Max=1 — at most one watch service per line. |
🔴 Validate Product Definition before go-live Use the "Validate Product Definition" action on every bundle before UAT. It identifies cardinality violations, missing required defaults, and structural errors with corrective action suggestions.
🔄 Block 9 — Product Selling Models: How Products Are Sold and Billed
What it is: A Product Selling Model defines how a product is sold: One Time, Term-Defined (subscription with end date), or Evergreen (until cancelled). Selling models directly govern billing cadence, proration behaviour, and renewal eligibility.
| Type | When to use | Comuniqa Products |
|---|---|---|
| One Time | Single charge, no recurring billing. | Phone Number Portability (one-time port fee); device purchases. |
| Term-Defined | Subscription with a defined end date. Enables auto-renewal flag. | Comuniqa Go! with 12-month or 24-month contract. |
| Evergreen | Subscription with no end date — continues until explicitly cancelled. | Comuniqa Go! no contract (billed monthly until cancelled). MoviMundo Plus+. |
⚠ Critical constraint Once a Price Book Entry is created with a Product Selling Model, the selling model cannot be changed. Validate in a sandbox and confirm with the billing team before creating any production Price Book Entries.
✅ Block 10 — Qualification Rules: Runtime Product Eligibility
What it is: Qualification Rules determine which products are eligible for a specific customer at runtime — before any product selection, configuration, or pricing occurs.
| Type | Logic | Comuniqa Example |
|---|---|---|
| Qualification | Product IS qualified when criteria ARE met. | Comuniqa Go! Youth: qualified ONLY when customer age ≤ 18. |
| Disqualification | Product IS disqualified when criteria ARE met. | Product hidden for accounts with outstanding debt balance > 0. |
🇦🇷 Comuniqa's 6 Qualification Rules
- Customer Age Validation: age > 18 → Fail (blocks Comuniqa Go! Youth)
- Outstanding Amount: outstandingAmount > 0 → Fail
- Max Active Mobile Lines: activeLines ≥ maxLines → Fail
- Credit Check: creditScore < minCreditScore → Fail
- Vida Digital Add-On Validation: Count(mandatory) ≠ 2 OR Count(optional) ≠ 1 → Fail
- YouTube Mundo Google Account Validation: GoogleEmail null or invalid → Fail
04 Capabilities
Capabilities Breakdown
Core Capabilities
✓ Catalogs & Category Hierarchy (5 levels)
✓ Product Classifications (attribute templates)
✓ Sub-Classifications (3-level hierarchy)
✓ Dynamic Attributes (8 data types)
✓ Attribute Picklists (reusable)
✓ Simple Products (static & configurable)
✓ Bundle Products (static & configurable)
✓ Product Groups (mandatory in configurable bundles)
✓ Local & Group Cardinality
✓ Product Selling Models (One Time / Term / Evergreen)
✓ Qualification & Disqualification Rules
✓ Product Discovery (Browse Catalogs UX)
✓ Commercial vs Technical Specification Types
✓ Attribute Override in Bundle Context
✓ Deep Clone Products
✓ Bulk CSV Import
Advanced / Extended Capabilities
⚡ Indexed Search (up to 4M products)
⚡ Semantic Search (Einstein AI)
⚡ Faceted / Guided Product Selection
⚡ Product Discovery Pricing Procedure
⚡ Einstein AI Product Description Generation
⚡ Data Translation (multilingual catalogs)
⚡ PCM Cache Layer (Product Details API)
⚡ Ramp Deal Segments
⚡ Decimal Quantity / Unit of Measure
⚡ Apex Hooks in Product Discovery Procedure Plan
⚡ Dynamic Options (Product Classification Component)
Cardinality Design — Comuniqa Vida Digital Pass
| Level | Cardinality Type | Min | Max | Comuniqa Design |
|---|---|---|---|---|
| Additional Benefits Group | Group Cardinality | 1 | 2 | Customer must pick at least 1, at most 2 optional components |
| Each Optional Component | Local Cardinality | 0 | 1 | Each individual add-on: optional, not default, max 1 instance |
| Base Benefits Group (Mi Coto + Club Día) | Group + Local | 2 | 2 | Both required and default — customer cannot deselect them |
05 Limitations
Limitations & Constraints
Documented Platform Limits
📦 Bundle Hierarchy Depth — Max 3 Levels
A product bundle hierarchy supports a maximum of 3 levels, where a parent can have up to 5 child nodes at a given level. For Comuniqa, the Comuniqa Go! bundle (root) → Group → Product is already 3 levels deep. Any requirement to nest further must be handled at design time. This limit cannot be exceeded.
🏷️ Attributes per Product — Max 200 Dynamic Attributes
A simple or bundle product can have up to 200 dynamic attributes. Comuniqa's Comuniqa Go! has approximately 10 commercial attributes — well within limits. However, if technical attributes were incorrectly added to commercial products, this limit becomes a maintenance concern at scale.
🔄 No Native Product Versioning
PCM does not support Product Versioning (this was available in Industries EPC but not in RCA PCM). When a product is modified — for example, Comuniqa changes the Data Speed Beyond Allowance from "5Mbps" to "10Mbps" — there is no platform-native way to version the product. This must be managed via separate product records or external governance processes.
🔀 Static vs Configurable Bundle Mixing
Static bundles can only contain static simple or static bundle child components. You cannot add configurable products as child components of a static bundle. A common trap when teams attempt to convert static bundles to configurable later without restructuring the hierarchy.
🔢 Product Classification Hierarchy — Max 3 Levels Deep
Product sub-classification hierarchies support up to 3 levels deep. For Comuniqa, a classification like "Mobile Product" → "Postpaid Plan" → "Youth Plan" is valid at 3 levels. Going deeper requires flattening the hierarchy or using a different classification strategy.
🔍 Search Index — Max 1M Products (Full), 2K Partial
By default, you can fully index up to 1,000,000 products and partially index up to 2,000 products. Search is limited to 25 searchable and 40 filterable fields/attributes combined. Full reindex is required after structural changes to the catalog.
Architectural Constraints
⚠ Groups Are Mandatory in Configurable Bundles
Child components in a configurable bundle MUST be placed under Groups — they cannot be added directly under the root product. This is non-negotiable and cannot be changed after the bundle is built without restructuring the entire hierarchy.
⚠ Product Classification Attributes Cannot Be Easily Removed
When you unassign an attribute from a product classification, its status changes to Inactive across all products inheriting from that classification. Removing "SIM Card Format" from the Mobile Plan classification after products are live is a significant operation requiring careful audit of all active orders and assets first.
06 Implementation Challenges
Common Implementation Challenges
⚠ Real-World Mistakes — Comuniqa Context
- Technical Attributes on Commercial Products: The team adds ICCID, provisioning codes, and network routing IDs to the Comuniqa Go! commercial product "for convenience." The commercial catalog becomes cluttered, agents see irrelevant fields, and the Product Discovery UX degrades. Rule: technical attributes belong on Technical specification type products only.
- Skipping Product Classifications: Products are built by assigning attributes directly. When 20 mobile plans need the same "Contract Term" attribute updated, it must be changed on each product individually. Always use classifications as the primary attribute assignment mechanism.
- Wrong Cardinality on Additional Benefits Group: Configured with Min=0, Max=5 instead of Min=1, Max=2. Customers can now subscribe to all 5 optional add-ons, and some choose 0 (violating bundle completeness). Cardinality must be UAT-tested with all boundary conditions before go-live.
- Bundle Root Is Not Assetizable: Team deselects "Is Assetizable" on the bundle root. DRO cannot create a parent asset, breaking the customer's account view and amendment flows. Is Assetizable on the root product applies to ALL child components in the bundle.
- Mutual Exclusivity Not Enforced in PCM: Team assumes the pricing engine will handle the MoviMundo Plus+ / Basic+ mutual exclusivity. The correct design is a Configurator compatibility rule reading from PCM group cardinality (Partner VAS group: Max=1). PCM defines the structure; the Configurator enforces it.
- No Effective Dates on Products: Comuniqa launches a promotional plan without setting Discontinued Date. When the promotion ends, agents continue adding the product to new orders. Availability Date and Discontinued Date must be part of every product launch governance process.
- Catalog Not Indexed After Bulk Product Import: Team imports 50 new products via CSV. Agents browse the catalog and see stale data — new products don't appear. After bulk changes, a partial or full index rebuild is required.
- Sub-classification Not Used for Youth vs Adult Plans: Two entirely separate classifications are created, duplicating 8 shared attributes. When shared attributes need updating, both classifications must be modified. Sub-classifications exist precisely to prevent this.
Downstream Impact — What a Bad Catalog Design Breaks
| PCM Design Error | Downstream Impact |
|---|---|
| Wrong cardinality on add-on group | Configurator allows invalid combinations → invalid orders → fulfillment failures → billing errors |
| Missing selling model assignment | Pricing engine cannot calculate subscription charges → quote shows zero price → billing generates no schedules |
| Is Assetizable = false on bundle root | DRO cannot create asset hierarchy → amendments and renewals break for all customers on that product |
| Technical attributes on commercial product | Agents accidentally modify provisioning codes → network activation fails → customer can't use their service |
| Product not active / discontinued date in past | Product invisible in Browse Catalogs → agents call support → conversion loss |
| Missing picklist value (e.g., "eSIM" not on SIM Format) | Agent cannot set required attribute → order blocks at validation → customer sale lost |
07 Boundaries
What This Functionality Cannot Cover
| Comuniqa Scenario | Why PCM Is NOT the Answer | Correct Engine |
|---|---|---|
| Blocking a customer aged 19+ from subscribing to Comuniqa Go! Youth | Age-based eligibility gating is a runtime qualification rule — not a PCM catalog property. | Qualification Rules (BRE + Context) |
| Enforcing that MoviMundo Plus+ and Basic+ cannot both be on the same order | PCM defines the Partner VAS group with Max=1, but enforcement at runtime is the Configurator's job. | Product Configurator (Advanced Config) |
| Calculating the 25% contract discount on Comuniqa Go! | PCM defines the "Contract Term" attribute and selling model. The discount calculation is a Pricing Procedure + Decision Table concern. | Salesforce Pricing Engine |
| Provisioning the ICCID from the inventory system | ICCID is a fulfillment-populated attribute in PCM (the slot exists). The actual provisioning is a DRO fulfillment task. | DRO + Inventory Integration |
| Generating a monthly ARS invoice for Comuniqa Go! | PCM defines the selling model. Billing schedule generation and invoice creation happen in Salesforce Billing. | Salesforce Billing |
| Storing the customer's usage data (how many MB consumed) | PCM defines usage product attributes but does not process or store usage events. | External Usage Mediation / Rate Management |
Architect Principle
PCM answers ONE question: "What exists to be sold, and how is it structured?" It does not answer "Can this customer buy it?" (Qualification), "How much does it cost?" (Pricing), "How do we deliver it?" (DRO/Fulfillment), or "How do we bill for it?" (Billing). Each of those concerns has its own engine — and they all depend on PCM as their data source.
08 Architecture
Architectural Decision Guidance
Decision Patterns for Comuniqa
Should Comuniqa Go! Youth and Comuniqa Go! Standard be separate products or one product with an attribute?
✅ If pricing, bundle structure, and fulfillment are IDENTICAL →
Use ONE product with a "Customer Segment" attribute. Use Qualification Rules to restrict to age ≤18.
⚠ If pricing, attributes, or bundle structure DIFFER →
Use SEPARATE products. Comuniqa Go! Youth is specifically positioned as a distinct product — keep it separate.
Should MoviMundo Plus+ and Basic+ be bundle components or standalone products?
✅ If they can be sold BOTH standalone AND as bundle add-ons →
Define them as simple products. Add as optional components in the Partner VAS group. Bundle-Based Adjustment Schedule zeros the price within the bundle. Comuniqa's design follows this pattern exactly.
How many Product Classifications does Comuniqa need?
✅ Recommended pattern →
One classification per product "type": "Mobile Plan Attributes", "Watch Service Attributes", "Streaming Pass Attributes", "SIM Attributes", "Phone Number Attributes", "Portability Attributes", "Family Bundle Attributes".
Best-Practice Design Patterns
🏗 Pattern: Commercial / Technical Catalog Separation
Maintain two parallel catalog streams. The Commercial catalog (Specification Type = Commercial) contains all customer-facing products. The Technical catalog contains provisioning-level sub-components. DRO maps commercial order products to technical fulfillment tasks. Sales agents never see — and cannot accidentally modify — technical products. This is the single most important structural decision in Comuniqa's PCM design.
🎯 Pattern: Deep Clone for Product Family Variants
When Comuniqa launches a new streaming pass, use Deep Clone to copy the existing pass product including all attributes, child components, and selling models. Modify only what changes (name, pricing, partner). Deep Clone copies attribute definitions, child component structure, and selling model options — not the pricing rules.
🔐 Pattern: Availability Dates as Governance Mechanism
All Comuniqa products should have an Availability Date and a Discontinued Date. Promotional products should have both set at launch — the system automatically hides them from Product Discovery after the Discontinued Date without requiring a manual deactivation step. This is the correct replacement for the lack of native product versioning.
🤖 Pattern: PCM Design for Agentforce API-First Consumption
The Agentforce quoting agent reads product data via the Product Details API and uses the PCM cache. For Comuniqa: (1) every product must have a meaningful Product Code, (2) all required attributes must have well-defined picklist values with display values set, (3) the PCM cache must be scheduled to refresh after bulk product updates, (4) qualification procedures must be designed as stateless API-callable functions. Products designed only for UI consumption will fail in headless API scenarios.
When NOT to Use PCM Features
✗ Runtime eligibility checks (use Qualification Rules)
✗ Price calculations (use Pricing Procedures)
✗ Enforcing mutual exclusivity at order time (use Configurator)
✗ Storing usage events or consumption data
✗ Managing customer contracts or T&Cs
✗ Invoice generation (use Billing)
✦ Knowledge Check
Knowledge Check — 10 Questions
All questions are grounded in the Comuniqa product model. Architect-level reasoning required.
Question 1 of 10 — Bundle Structure
Comuniqa's implementation team wants to add "MoviMundo Plus+" directly under the "Comuniqa Go! (Vida Digital)" bundle root without placing it in a Product Group first. Is this architecturally valid for a configurable bundle?
A) Yes — product components can be placed directly under a configurable bundle root for simplicity.
B) No — in a configurable bundle, child components MUST be placed under Product Groups. Groups are mandatory in configurable bundles.
C) Yes — but only for optional components. Required components must be under groups.
D) No — MoviMundo Plus+ must be a separate standalone product and cannot be a bundle component at all.
Question 2 of 10 — Attribute Architecture
The Comuniqa product team asks whether to store the ICCID (SIM card serial number) on the commercial SIM Card product record, or on a separate technical product. What is the correct architectural decision?
A) Store it on the commercial product — it's a key customer identifier that agents need to see.
B) Store it on the commercial product as a fulfillment-populated, read-only attribute. ICCID is customer-facing but system-generated — visible in the customer account but never editable by agents.
C) Store it on a technical product only — it's a system identifier and should never appear on commercial records.
D) Do not store it in PCM at all — ICCID belongs only in the provisioning system.
Question 3 of 10 — Cardinality
📋 The Comuniqa Vida Digital Pass Additional Benefits group must enforce that a customer selects minimum 1 and maximum 2 optional components. There are 5 optional components available.
Where and how is this rule configured in PCM?
A) As a Qualification Rule on the product that checks the number of selected components at runtime.
B) As a pricing rule that zeroes out any components beyond the second selection.
C) As Group Cardinality on the Additional Benefits Product Group: Min = 1, Max = 2. Each component has Local Cardinality: optional, not default, min qty 0, max qty 1. Enforced by the Configurator at runtime reading PCM cardinality settings.
D) As a validation rule on the Product object using Salesforce formula fields.
Question 4 of 10 — Product Classification
Comuniqa needs to create two products: "Comuniqa Go! Two" and "Comuniqa Go! Shared Two". Both have the same attributes but slightly different pricing and selling behavior. What is the most maintainable PCM design?
A) Create both products from scratch, assigning attributes directly to each product without using a classification.
B) Create one Product Classification "Watch Service Attributes" with the three shared attributes. Base both products on this classification. Override only what differs. When attribute updates are needed, update the classification once and both products inherit the change.
C) Create one product "Comuniqa Go! Two" with a "Variant" picklist attribute for Standard vs Shared.
D) Create a parent product "Watch Services" and make both variants child components of it.
Question 5 of 10 — Specification Types
📋 A network engineer requests that internal routing plan codes and MSISDN range assignments be added as attributes to the Comuniqa Go! product so fulfillment teams can reference them during order processing.
Should these attributes be added to the commercial Comuniqa Go! product?
A) Yes — adding them to the commercial product makes them accessible to all teams in one place.
B) No — routing plan codes and MSISDN range assignments are internal provisioning attributes that should live on a Technical specification type product. Adding them to the commercial record clutters Product Discovery, risks agent modification, and violates the commercial/technical separation design principle.
C) Yes, but mark them as IsHidden = true so agents can't see them.
D) It depends on whether the provisioning platform can call the Salesforce API.
Question 6 of 10 — Selling Models
Comuniqa Go! can be sold with three commitment options: No Contract (month-to-month), 12-Month Contract, and 24-Month Contract. How should this be modelled using Product Selling Models in PCM?
A) Create three separate Comuniqa Go! products — one for each contract option.
B) Create one Evergreen selling model with a "Contract Term" attribute that the agent fills in at order time.
C) Create three Product Selling Model Options on the same Comuniqa Go! product: (1) Evergreen — Pricing Term 1 Month, (2) Term-Defined — Pricing Term 12 Months, (3) Term-Defined — Pricing Term 24 Months. The Contract Term attribute captures the customer's selection.
D) Create one Term-Defined selling model with a minimum term of 1 month and a maximum of 24 months.
Question 7 of 10 — PCM Limits
📋 A catalog admin has just bulk-imported 150 new promotional product variants via CSV. The next morning, agents report that the new products are not appearing in Product Discovery's Browse Catalogs, even though the import log shows success.
What is the most likely root cause and resolution?
A) The products were imported without a Price Book Entry — they must be priced before they appear.
B) The products need to be assigned to catalog categories before they appear in Browse Catalogs.
C) The product search index was not rebuilt after the bulk import. After any bulk product changes, a partial or full index rebuild is required for new products to appear in the indexed Product Discovery listing. The admin must trigger a Rebuild Index from Index and Search Configuration.
D) The imported products are in Draft status by default — they must be manually activated one by one.
Question 8 of 10 — Bundle Assetization
A Comuniqa implementation architect sets "Is Assetizable = false" on the "Comuniqa Go! (Vida Digital)" bundle root product to reduce asset records and simplify the data model. What will be the downstream impact?
A) No impact — child components can still be assetized independently regardless of the root setting.
B) The Is Assetizable setting on the root product applies to ALL child components in the bundle. Setting it to false means NO assets will be created for the bundle or any of its children — including the SIM Card and Phone Number. This breaks amendment flows, renewal workflows, and the customer's account view.
C) Only the bundle root will not be assetized. Child components with their own Is Assetizable = true will still create assets.
D) The setting will only affect new orders — existing customers' assets are unaffected.
Question 9 of 10 — Qualification Rules
📋 The "Comuniqa Go! Youth" plan should only be available to customers aged 18 or under. A developer proposes adding an "IsYouthEligible" boolean attribute to the product, and having agents manually check a box to confirm eligibility.
Why is this a poor architectural design, and what is the correct approach?
A) It's acceptable as a quick interim solution, as long as there's a validation rule to enforce the checkbox.
B) This is incorrect for two reasons: (1) Age eligibility is a business rule that should be enforced automatically, not a manual checkbox prone to agent error. (2) Product attributes define WHAT a product is, not who can buy it. The correct approach is a Qualification Rule using Customer Age Validation logic — it runs before product selection, is automatic, and provides a clear failure message.
C) It would work, but the attribute should be a picklist instead of a boolean for flexibility.
D) Correct design — PCM attributes are the right place to store eligibility state that varies per customer interaction.
Question 10 of 10 — Product Versioning
📋 Comuniqa wants to update the "Data Speed Beyond Allowance" attribute on Comuniqa Go! from "5Mbps" to "10Mbps" for new subscriptions starting next month, while existing customers keep the 5Mbps specification per their contract terms.
How should this be handled given PCM's lack of native product versioning?
A) Update the attribute value on the existing product — all new and existing quotes will automatically use the new value.
B) Use PCM's built-in version management to create a new product version with the updated attribute value.
C) PCM has no native product versioning. The recommended approach is to create a new product record "Comuniqa Go! v2" with Availability Date set to the effective change date, and set a Discontinued Date on the original product. Existing assets remain linked to the original record. New quotes use the new product.
D) Store the attribute value on the customer's Account record instead, so it can be individually managed per customer.