Product Catalog Management: o catálogo como fonte única da verdade
Por que o PCM existe, seu modelo de dados (Catalog → Category → Product2), Selling Models, tipos de produto e o ecossistema de atributos reutilizáveis.
Quinto post da série: um panorama do Product Catalog Management antes dos módulos dedicados. O que o PCM resolve em relação aos catálogos legados, a hierarquia Catalog → Category → Product2, os três Selling Models, Simple vs Bundled, Static vs Configurable, os limites de bundle e como atributos viram blocos reutilizáveis via Classifications.
Visão de cima antes dos módulos
Antes de mergulhar nos módulos, vale uma visão de cima de quatro peças que você vai usar o tempo todo — Product Catalog Management, Selling Models, Pricing Procedures e Transaction Line Editor. Começamos pelo Product Catalog Management — o que ele resolve, seu modelo de dados e os tipos de produto. (Cada tema tem um módulo dedicado mais à frente; aqui é o panorama.)
Por que PCM existe?
O problema dos catálogos legados:
- ❌ Catálogo legado — produtos espalhados por planilhas, atributos duplicados (Color recriado em cada produto), configuração no improviso na Quote Line, difícil de versionar — cada bundle vira retrabalho manual.
- ✅ Com PCM — single source of truth, atributos reutilizáveis (1 vez → vários produtos), hierarquia clara (Catalog → Category → Product), validação automática de bundles, versionamento + governança nativos.
Modelo de dados do PCM
Hierarquia + ecossistema de atributos:
- Catalog — coleção publicável.
- Category — até 100.000 produtos.
- Product2 — o item core — conecta com Selling Model, Attribute Definitions, Attribute Picklist Values, Product Classifications e Bundle Hierarchy (até 3 níveis, excluindo o produto raiz).
Selling Model: como o produto é comercializado
São três tipos:
- One-Time — venda única, sem recorrência.
- Term-Defined — assinatura com data de término fixa, ex.: contrato de 12 meses.
- Evergreen — assinatura que recorre até ser cancelada.
Atenção: cobrança por consumo não é um selling model — ela vive no
UsageModelTypedo próprio produto, combinada com Term-Defined ou Evergreen.
Simple vs Bundled
Dois tipos fundamentais de produto:
- Simple Product — item standalone, sem hierarquia. Ex.: notebook avulso, licença individual, taxa de setup, consultoria por hora.
- Bundled Product — grupo vendido junto. Ex.: notebook + mouse + monitor, software + 5 licenças + suporte, plano + aparelho + capa.
Static vs Configurable
Quando o sales rep pode mexer no bundle:
- Static — vende como está — o rep não customiza. Combos fixos, promoções pré-empacotadas, edições enterprise/pro/free.
- Configurable — o rep escolhe componentes/quantidades. "Monte seu plano", bundles flexíveis, pacotes com add-ons.
A hierarquia de bundle tem limites de plataforma em profundidade, componentes e overrides — conhecê-los guia a modelagem. Bater nesses tetos costuma ser sinal de modelagem errada (quebre em sub-bundles ou use Classifications):
| Limite do bundle | Valor |
|---|---|
| Profundidade da hierarquia | 3 níveis (excluindo o produto raiz) |
| Componentes por bundle | 200 |
| Attribute overrides por bundle | 200 |
| Product component overrides por bundle | 10 |
| Group component overrides por bundle | 10 |
Ecossistema de atributos
Como atributos viram blocos reutilizáveis — leia de baixo para cima: valores compõem uma Definition, Definitions se agrupam numa Category, a Classification vira template e o Product2 herda tudo.
| Camada | Exemplo |
|---|---|
| Attribute Picklist Value | White, Blue, Pink |
| Attribute Definition | Color (picklist) |
| Attribute Category | Garments (Color, Fabric) |
| Product Classification | Garment Type (template) — até 200 produtos por classificação, com no máximo 15 dynamic attributes por produto |
| Product2 | T-Shirt (herda os atributos) |
Diferente do CPQ legado (onde atributos viravam campos custom em Quote Lines), no PCM eles são definidos uma vez e herdados — sem duplicação.
⚡ Atualização Agentforce 2026
O Advanced Configurator substitui regras if-then frágeis por constraint-based logic: você declara o que precisa ser verdadeiro e o solver evita combinações inválidas. A inheritance via Classifications deixa você definir atributos uma vez no template e os produtos derivados herdam — como herança de classe em programação.
Nas próximas aulas do módulo, entramos em Selling Models a fundo, Pricing Procedures e o Transaction Line Editor. As aulas anteriores cobriram os seis objetos centrais, o Pricing Waterfall e o caminho da Quote à Order.