revenue-cloud-pcm

name	revenue-cloud-pcm
description	Salesforce Revenue Cloud Product Catalog Management (PCM) master data on core Salesforce objects for Agentforce Revenue Management, Revenue Cloud Advanced, and Revenue Cloud Billing. Use for any lookup, query, design, build, export, import, migration, CSV, sandbox load, troubleshooting, or analysis involving catalogs, categories, products, bundles, classifications, dynamic attributes, picklists, qualification/disqualification, selling models, Product Discovery, Product2, ProductCatalog, ProductCategory, ProductCategoryProduct, AttributeDefinition, AttributePicklist, AttributePicklistValue, AttributeCategory, AttributeCategoryAttribute, AttrPicklistExcludedValue, ProductClassification, ProductClassificationAttr, ProductClassificationParent, ProductAttributeDefinition, ProductRelatedComponent, ProductComponentGroup, ProductComponentGrpOverride, ProductRelComponentOverride, ProductRelationshipType, ProductQualification, ProductDisqualification, ProductCategoryQualification, ProductCategoryDisqual, ProductSellingModel, ProductSellingModelOption, ProductRampSegment, ProductSpecificationType, or ProductSpecificationRecType. Do not drift to legacy Salesforce CPQ SBQQ__ or legacy Salesforce Billing BLNG__ managed-package patterns unless explicitly requested.
license	MIT
metadata	{"author":"Rohit Radhakrishnan","version":"1.0.0","domain":"salesforce-revenue-cloud","module":"product-catalog-management"}

Salesforce Product Catalog Management (PCM)

You are helping with Salesforce Product Catalog Management in Salesforce Revenue Cloud / Agentforce Revenue Management / Revenue Cloud Advanced / Revenue Cloud Billing. This is the newer core-platform product family that uses standard/core Salesforce objects such as Product2, Quote, QuoteLineItem, ProductClassification, and related PCM objects. Do not drift into legacy managed-package Salesforce CPQ (SBQQ__) or legacy Salesforce Billing (BLNG__) patterns unless the user explicitly asks for those products.

PCM models the company's product portfolio — catalogs, categories, products, bundles, dynamic attributes, classifications, qualification rules, selling models, and the Product Discovery experience.

This file is your routing layer. It contains the gotchas you must always remember and a map of when to load which reference. Do not try to answer detailed PCM questions from this file alone — load the right reference first.

Always-true gotchas (never forget these)

These are the corrections most agents need before they can be useful in PCM. Internalize them:

1. Bundles use a TWO-table structure, not one. A configurable bundle has both ProductRelatedComponent (the line linking a child to a parent) and ProductComponentGroup (the section the line belongs to). Static bundles can skip groups; configurable bundles cannot. Don't model a bundle without thinking through both.
2. Attributes can be attached at TWO levels. ProductClassificationAttr defines the template attribute on a classification. ProductAttributeDefinition is the instance attached to a specific Product2. A product based on a classification inherits its attributes; you only create a ProductAttributeDefinition when overriding an inherited attribute on a specific product or adding a one-off attribute. Confusing these two is the most common PCM modeling error.
3. Qualification rules default to qualified. A product or category with NO qualification/disqualification record is visible. Qualification beats disqualification when both apply. Don't write a rule "to make it visible" — write a rule to restrict visibility.
4. ProductSellingModel is its own object, not a Product2 picklist. Pricing term length and unit live on ProductSellingModel. A product is linked to one or more selling models via ProductSellingModelOption. Pricing (rates, books) lives in a separate Salesforce Pricing module — do NOT try to put price on Product2 directly for PCM-driven flows.
5. Product2.Type = 'Bundle' is the switch that turns a product into a bundle. Without it, ProductRelatedComponent rows pointing to it will not be treated as bundle components by the runtime. Also set ConfigureDuringSale correctly: Allowed (configurable), Not Allowed (static), or None (simple product).
6. Product2.BasedOnId (the classification link) is what makes a product inherit attributes. Setting BasedOnId is mandatory before you can rely on classification-driven attributes; without it, you have to attach every attribute via ProductAttributeDefinition directly.
7. Catalogs and categories are time-bounded. EffectiveStartDate / EffectiveEndDate on Catalog, and EffectiveFromDate / EffectiveToDate on qualification/disqualification rules. A "missing" product in Product Discovery is most often an expired effective-window, not a permission or rule problem.
8. API version matters. Most PCM objects appear in API v60.0+. Some (ProductRampSegment, IsNavigational, ProductComponentGroup.ParentGroupId, Product2.UsageModelType) are v62.0+. AttrPicklistExcludedValue is v61.0+. Check the API version of the org before assuming an object exists.
9. PCM is not standalone. It hands records off to Salesforce Pricing, Product Configurator, Transaction Management, and Billing. A "wrong" PCM model often shows up as a downstream pricing or configurator error. When debugging, identify which module is actually emitting the error before changing PCM.
10. Permission set groups, not profiles. PCM ships permission sets: ProductCatalogManagementDesigner, ProductCatalogManagementViewer, plus community variants. Compose them via permission set groups; do not clone profiles.
11. Describe the org before data migration or bulk lookup work. Object and field API names vary by org/version: catalogs may expose as ProductCatalog rather than Catalog, and AttributePicklistValue may use PicklistId rather than AttributePicklistId.
12. This is not legacy managed-package CPQ/Billing. Revenue Cloud / Agentforce Revenue Management uses core objects and unnamespaced APIs for PCM. Avoid SBQQ__ CPQ and BLNG__ Billing assumptions, fields, and object names unless the user explicitly says they are working on those legacy managed packages.

When to load which reference

Read only the reference(s) relevant to the current task. Each reference is self-contained.

User intent	Load
"What is PCM?", architecture, how modules connect	references/01-architecture.md
Editions, license, permission sets, personas, setup	references/02-setup-and-permissions.md
Catalogs, categories, navigation, hierarchy, default catalog	references/03-catalogs-and-categories.md
Attribute definitions, picklists, attribute categories, validation	references/04-attributes.md
Product classifications, attribute templates, inheritance	references/05-product-classifications.md
Product creation, simple vs bundle, components, cardinality, overrides	references/06-products-and-bundles.md
Product variants (size/color/storage), variation parents	references/07-product-variants.md
Qualification / disqualification rules, decision tables, eligibility	references/08-qualification-rules.md
Selling models (one-time, term-defined, evergreen), proration, ramp	references/09-selling-models.md
Product Discovery, Browse Catalogs, Guided Selection, search	references/10-product-discovery.md
Hard limits — sizing, max attrs, max bundle depth, etc.	references/11-limits.md
Field-level lookup for ANY PCM object (Product2, AttributeDefinition, etc.)	references/12-object-reference.md
Catalog/bundle migration, CSV export, load order, target-org import	references/13-data-migration.md

When the user's question spans multiple areas (e.g., "build a configurable phone bundle with color and storage attributes"), load multiple references — but only the ones you need.

Standard workflows

These are the workflows that appear over and over. Follow the named steps; the detailed "how" is in the referenced file.

Workflow A — Stand up a new product catalog from scratch

1. Confirm editions and permission sets — load 02-setup-and-permissions.md.
2. Create the Catalog record with EffectiveStartDate, optional EffectiveEndDate, and CatalogType — load 03-catalogs-and-categories.md.
3. Build the category hierarchy under the catalog (max 5 levels deep, excluding root). Set IsNavigational for browse paths.
4. Create AttributeDefinition records for the attributes the products share. Group them with AttributeCategory if reusable — load 04-attributes.md.
5. Create ProductClassification templates and link attributes via ProductClassificationAttr — load 05-product-classifications.md.
6. Create Product2 records, set BasedOnId to the classification — load 06-products-and-bundles.md.
7. Link products to categories via ProductCategoryProduct.
8. Add ProductSellingModelOption rows tying each product to one or more ProductSellingModels — load 09-selling-models.md.
9. Add qualification rules only if you need to restrict visibility — load 08-qualification-rules.md.
10. Validate via Product Discovery — load 10-product-discovery.md.

Workflow B — Build a configurable bundle

1. Create the parent Product2 with Type = 'Bundle' and ConfigureDuringSale = 'Allowed'.
2. Create ProductComponentGroup rows for each section of the bundle (e.g., "Choose phone", "Choose plan").
3. For each child product, create ProductRelatedComponent, setting ParentProductId, ChildProductId, and ProductComponentGroupId. Set MinQuantity, MaxQuantity, Quantity, IsComponentRequired, IsDefaultComponent, IsQuantityEditable, QuoteVisibility.
4. If the bundle needs cardinality overrides for a particular root context, create ProductComponentGrpOverride (group cardinality) and/or ProductRelComponentOverride (component cardinality), tying both to a root OverrideContextId.
5. Cap: ≤200 components per bundle hierarchy, ≤600 attribute overrides, ≤10 component or group overrides per bundle. See references/11-limits.md.
6. Run Validate Product Definition in the UI before treating the bundle as ready.

Detail in references/06-products-and-bundles.md.

Workflow C — Add dynamic attributes to a product family

1. Decide: are the attributes shared across many products? If yes, attach via ProductClassification (template). If unique to one product, attach directly to Product2.
2. Create AttributeDefinition rows for each attribute (set DataType).
3. For picklist-typed attributes, create AttributePicklist and AttributePicklistValue rows.
4. Group attributes via AttributeCategory + AttributeCategoryAttribute if reusable.
5. Attach to template: ProductClassificationAttr rows.
6. To exclude specific picklist values for a classification or product, create AttrPicklistExcludedValue rows.
7. To override an attribute on a specific product, create ProductAttributeDefinition and set OverriddenProductAttributeDefinitionId.

Detail in references/04-attributes.md and references/05-product-classifications.md.

Workflow D — Diagnose "product is missing from Browse Catalogs"

Check in this order — most common cause first:

1. Product2.IsActive = true?
2. Product2.AvailabilityDate reached and DiscontinuedDate / EndOfLifeDate not yet passed?
3. ProductCategoryProduct row exists for the catalog category being browsed?
4. Catalog.EffectiveStartDate reached, EffectiveEndDate not passed?
5. ProductDisqualification or ProductCategoryDisqual record evaluating to IsDisqualified = true for current context?
6. Qualification procedure (if configured) returning false for this user?
7. Product Discovery search index up to date? (After bulk loads, a reindex is required.)
8. User has the right permission set (Viewer at minimum)?

Detail in references/08-qualification-rules.md and references/10-product-discovery.md.

Workflow E — Migrate catalog or bundle product data

1. Confirm the input mode: a catalog name/id/code, or one or more bundle Product2 ids/codes where Product2.Type = 'Bundle'.
2. Describe the source org schema before querying, especially ProductCatalog/Catalog and attribute picklist fields.
3. Expand the product graph through ProductRelatedComponent, collecting ChildProductId products and ChildProductClassificationId classifications. Recurse into child products that are bundles.
4. Include reusable attribute foundation objects (AttributeDefinition, AttributePicklist, AttributePicklistValue, AttributeCategory, AttributeCategoryAttribute) plus scoped classification/product attribute records.
5. Generate CSVs with source ids and helper business keys for lookup/remapping.
6. Load a target org in analyzed dependency order with checkpointed id mapping. The load package must be usable without source org access after export.

Detail in references/13-data-migration.md.

Available scripts

This skill bundles helper scripts under scripts/ for inspecting a Salesforce org's PCM data via the Salesforce CLI (sf). They require sf authenticated to a target org. Reference them only when the user wants to inspect or load real org data.

• scripts/describe-pcm-objects.sh — Runs sf sobject describe for every PCM object and writes the full schemas to pcm-describe/. Useful for confirming which fields exist in a specific org/API version before writing queries.
• scripts/query-product-tree.sh — Given a Product2.Id of a bundle, recursively prints the bundle hierarchy with components, groups, and attributes. Use to validate a bundle was modeled correctly.
• scripts/list-catalogs.sh — Lists every active catalog with categories and product counts. Quick health check after a deploy.
• scripts/check-orphans.sh — Finds common modeling defects: products with Type = 'Bundle' but no components; classifications with no products; qualification rules with expired effective dates.

Each script prints --help with usage. They are read-only by default.

For fragile migration/export/import work, prefer a dedicated script over ad hoc SOQL. If adding migration scripts, use relative paths and explicit interfaces such as:

• scripts/export-pcm-migration.py — Export by --target-org, --catalog-name/--catalog-id or --bundle-product-id/--bundle-product-code, and --out-dir. It should write CSVs, a manifest, analyzed load order, and coverage notes.
• scripts/load-pcm-migration.py — Load a generated package into a target org with --target-org, interactive pauses, checkpointed id mapping, and local error reports. It must not require source org access.

Things this skill explicitly does NOT cover

These are adjacent modules. If the user crosses into them, say so and stop:

• Pricing math, price books, rate cards → Salesforce Pricing module (separate).
• Quote/order line creation, runtime configurator UI behavior → Product Configurator + Transaction Management.
• Billing operations outside PCM master data (invoicing, billing schedules, revenue recognition) → Revenue Cloud Billing/Billing module.
• Approval flows on quotes → Advanced Approvals.
• Asset and subscription lifecycle after order fulfillment → Dynamic Revenue Orchestrator.

PCM ends where the product is defined and discoverable. Anything past that belongs to a sibling module in the Revenue Cloud core product family. Do not switch to legacy SBQQ__ or BLNG__ managed-package behavior unless the user explicitly requests it.