Os seis objetos centrais do Revenue Cloud que você precisa dominar

Os seis objetos centrais do Revenue Cloud — o esqueleto que você precisa dominar

Todo o Revenue Cloud gira em torno de seis objetos centrais — do produto que você vende até o dinheiro reconhecido no balanço. Memorize essa sequência: ela é o esqueleto do ciclo inteiro, e cada peça se desdobra em um módulo dedicado mais adiante. Se você não tiver clareza sobre como esses objetos se encadeiam, qualquer implementação vai começar torta.

A visão geral: seis objetos, seis etapas

Cada objeto cobre uma etapa distinta do ciclo de receita. Ao lado do nome amigável está o nome de API real — é como você os encontrará no modelo de dados, nos flows, nos Apex triggers e nas queries SOQL.

• Product (Product2) — o que sua empresa vende.
• Price Book (Pricebook2 · PricebookEntry) — a tabela de preços, que varia por contexto: cliente, canal, moeda.
• Quote (Quote · QuoteLineItem) — a proposta comercial enviada ao cliente.
• Order (Order · OrderItem) — a compra confirmada, pronta para fulfillment.
• Contract (Contract) — o acordo de longo prazo que sustenta renovações e subscriptions.
• Billing — fatura, pagamento e reconhecimento de receita.

1 · Product — a fundação de tudo

"Sem produto não existe receita." O Product2 é o ponto de partida: é ele que você precifica, agrupa em bundles e vende. É também o single source of truth que conecta venda, fulfillment e billing.

Um produto pode ser um bem físico, um serviço, uma subscription ou algo cobrado por consumo, como usage-based. Pode existir sozinho, como standalone, ou como parte de um bundle hierárquico, carregando atributos reutilizáveis — cor, tamanho, plano, quantidade, faixa de consumo e assim por diante. Na hierarquia do catálogo, ele vive em:

Catalog → Category → Product

Essa hierarquia não é cosmética. Ela define como o catálogo é navegado no CPQ, no RLM e nas experiências de self-service. Modelar mal aqui significa refatorar o catálogo inteiro depois — um custo alto que implementações apressadas costumam descobrir tarde demais.

2 · Price Book & Price Book Entries — onde mora o preço

O Price Book (Pricebook2) é a tabela de preços. Sempre existe o Standard Price Book, e você cria quantos price books customizados forem necessários. A ponte entre um produto e um preço é o Price Book Entry (PricebookEntry): ele liga um Product2 a um valor dentro de um Price Book específico.

A relação é 1 Product → N Price Book Entries → N Price Books. Por que o mesmo produto teria preços diferentes? Porque preço raramente é absoluto; quase sempre ele depende do contexto comercial:

• Tipo de cliente: varejo vs. atacado vs. parceiro.
• Estratégia de venda: B2C vs. B2B.
• Região / moeda: USA $ · BR R$ · EU €.
• Canal: venda direta vs. distribuidor.

Ignorar essa separação e empurrar tudo no Standard Price Book é um dos erros de modelagem mais comuns — e um dos mais caros de corrigir depois. Quando o segundo canal de vendas aparecer, o problema vai estar enterrado no núcleo do modelo de dados.

3 · Quote & Quote Line Items — a proposta comercial

Antes de fechar negócio, o cliente B2B normalmente pede uma cotação formal: uma lista de produtos, preços, descontos e condições comerciais. Essa é a Quote (Quote), e cada item dela é um Quote Line Item (QuoteLineItem).

Uma Quote reúne os produtos selecionados, seus preços e descontos, os termos comerciais e a validade da proposta. Um exemplo simples ficaria assim:

Quote Q-0042 · ACME CorpProdutoQtd.PreçoLaptop Pro 14"2$1.200Office Suite Subscription5$60/mêsPremium Support1$500Total proposto—$3.100 + subscription Na prática, a Quote é onde a complexidade comercial começa a aparecer: desconto por volume, aprovação de margem, bundle, co-termo, ramp, produto recorrente, produto one-time, add-on, renovação e por aí vai. Por isso, tratar Quote como “só uma proposta em PDF” é uma visão muito limitada. Ela é a fotografia comercial antes do compromisso virar pedido.

4 · Order — a compra confirmada

Quando o cliente aceita a Quote, ela vira uma Order — manualmente, por automação ou via action do Agentforce. No caso simples, os Order Products (OrderItem) espelham os Quote Line Items em uma relação 1:1.

Dois estados que você precisa ter internalizados:

• Draft: ainda é possível editar quantidades, preços e descontos, dependendo da configuração.
• Activated: as linhas ficam trancadas para alteração direta e o processo passa a alimentar fulfillment, assets, contratos e billing.

O fluxo que conecta proposta, confirmação e posse é direto:

1. Quote — proposta aguardando aceite do cliente.
2. Order — compra confirmada, pronta para fulfillment após ativação.
3. Asset — o que o cliente efetivamente possui, registrado na Account.

⚠️ Cuidado com o “1:1”

O espelho Quote Line → Order Product é o caso simples — primeira venda, sem histórico e sem alteração contratual complexa. No RLM, ações de amend, cancel e renew sobre uma subscription podem gerar Order Products que não têm correspondência direta com uma Quote Line existente. Isso inclui linhas de redução, repricing, reconfiguração de bundle e ajustes registrados em objetos relacionados, como OrderItemDetail. Não trate o 1:1 como regra universal — você vai se arrepender na primeira renovação complexa.

5 · Contract — o acordo de longo prazo

Uma Order é um evento único. Serviços recorrentes — SaaS, telecom, mídia, suporte, manutenção — precisam de um contêiner que atravesse vários ciclos de billing, renovações e mudanças contratuais. Esse contêiner é o Contract.

Casos típicos onde o Contract entra em cena:

• Subscriptions de SaaS com renovação anual.
• Planos de telecom, como linha, dados e add-ons.
• Renovações automáticas via amendment ou renewal flow.
• Deals multi-anuais com ramp segments, ou seja, degraus de crescimento de receita ao longo do contrato.

A recorrência em si é representada por linhas de subscription e asset com período de vigência definido. É essa estrutura que sustenta as operações de amend e renew que vêm mais adiante no ciclo — e que tornam o Contract um dos objetos mais mal compreendidos em implementações apressadas.

Quando alguém subestima o Contract na fase de design, o modelo inteiro perde consistência no momento em que o primeiro cliente pede uma renovação parcial, um cancelamento no meio do período ou um upgrade com co-termo.

6 · Billing & Revenue — fechar o ciclo

O último elo transforma compromissos comerciais em dinheiro e em registros contábeis. São três conceitos acionados depois da Order ativada — e, no caso de recorrência, depois da estrutura contratual estar corretamente formada:

• Invoice: a fatura emitida ao cliente, gerada por billing schedules configurados na Order, na Contract ou nos objetos relacionados ao modelo de billing.
• Payment: o recebimento do valor faturado, com matching da transação financeira.
• Revenue Recognition: o reconhecimento contábil da receita segundo normas como ASC 606 e IFRS 15.

Billing não é só emitir fatura. É o ponto onde erros de modelagem nos objetos anteriores se tornam problemas contábeis reais — com impacto em auditoria, fechamento fiscal e previsibilidade financeira. Quanto antes você entender essa dependência na cadeia, menos surpresas desagradáveis vai encontrar no go-live.

Como tudo se encadeia

Juntando as peças, o Revenue Lifecycle é uma corrente contínua:

Product → Price Book Entry → Quote → Order → Contract → Billing

O Asset (Asset) nasce quando a Order é ativada: é o registro, na conta do cliente, daquilo que ele possui — e o ponto de partida de renovações, amendments e upsells futuros. Cada elo que você dominar é um pedaço dessa corrente. Pule um, e o modelo inteiro perde coerência.

Como o Agentforce organiza esses objetos na geração atual

Na geração atual da plataforma, os objetos do ciclo se organizam em cinco categorias funcionais — cada uma agrupando os objetos daquela etapa e podendo ter agentes de IA dedicados para quoting, aprovações, renovações e faturamento:

• Product Catalog & Pricing — Product · Price Book.
• Transaction Management — Quote · Quote Lines.
• Contract Lifecycle — Contract · Amendments · Asset.
• Order-to-Cash — Order · Order Products.
• Billing — Invoice · Payment · Revenue.

Essa categorização não é só nomenclatura de marketing: ela reflete como permissões, automações, responsabilidades e agentes de IA podem ser organizados na plataforma. Conhecer os seis objetos-âncora sem entender em qual categoria funcional cada um vive é saber o nome sem saber o endereço — e torna qualquer conversa sobre governança, desenho de solução ou segmentação de responsabilidades muito mais difícil do que deveria ser.