Winter '27: Revenue Cloud vira Agentforce Revenue Management
A release em que o motor de receita do Salesforce para de ser uma coleção de módulos.
Winter '27 não é atualização incremental do Revenue Cloud, é consolidação arquitetural. O produto ganha novo nome, entra no Salesforce Go e passa a tratar catálogo, preço, cotação, aprovação, fulfillment e billing como um fluxo contínuo. Abro a série com o panorama das sete mudanças que importam.
Conteúdo de pré-release: as funcionalidades ainda podem mudar antes da disponibilidade geral, e licenças, permissões e etapas de ativação variam por edição. Separo sempre o que a Salesforce anunciou do que eu consegui observar direto na org.
Eu acompanho release notes de Revenue Cloud há tempo suficiente para reconhecer quando uma release é cosmética e quando ela mexe na fundação. Winter '27 é do segundo tipo. O nome novo: Agentforce Revenue Management, é a parte menos interessante; o que interessa é o que ele sinaliza.
Até aqui, quem implementava Revenue Cloud lidava com ilhas: CPQ de um lado, billing de outro, contratos num terceiro canto, e integrações caseiras costurando tudo. Winter '27 ataca exatamente essa costura.
As sete mudanças que importam
- Agentforce sai da periferia. O Approval Agent passa a submeter, revogar, pesquisar, resumir e decidir sobre aprovações.
- Promoções viram cidadãs de primeira classe, com elegibilidade, canais, empilhamento, objetos e APIs próprias.
- O teto operacional sobe para 15 mil linhas em pricing, configuração e geração documental.
- Ramp deals ganham uplift composto e ajustes retroativos.
- Billing ganha cadências flexíveis, forecast e automação de documentos de fatura.
- O Dynamic Revenue Orchestrator fica temporal, tratando o pedido como linha do tempo.
- Contracts aproxima governança e IA, com playbooks versionados e análise de redlines.
Salesforce Go: a mudança que ninguém comenta
O Salesforce Go reúne descoberta, ativação e configuração de recursos de Revenue num lugar só. Winter '27 adiciona orientação para Billing e um template pré-construído de orquestração de pedidos de alta tecnologia.
Parece detalhe de admin, e não é. A administração de Revenue Cloud sempre exigiu atravessar várias áreas de Setup, descobrindo dependências de licença no susto. O Go torna essas dependências explícitas, o que favorece uma trilha de adoção por capacidade em vez de um big bang técnico.
Um detalhe honesto da inspeção: a trilha aparece, mas a página detalhada carregou parcialmente e exibiu texto inconsistente de template durante o preview. O conteúdo guiado ainda está em estabilização.
Como eu testei
Ambiente de teste: scratch org Enterprise Edition, Winter '27, API 68.0, criada a partir de um Dev Hub de pré-release, com licenças de Revenue Cloud, Billing, Agentforce, Product Catalog Management e Dynamic Revenue Orchestrator.
Como o ambiente não tem massa transacional de produção, as capturas comprovam superfícies de configuração e modelo de dados. Limites de volume e fluxos ponta a ponta continuam dependendo de teste funcional, e eu digo em cada artigo o que consegui e o que não consegui verificar.
A leitura que importa
O valor da release não está numa tela. Está na continuidade entre catálogo, preço, configuração, cotação, aprovação, fulfillment, faturamento e contrato. É essa continuidade que torna Agentforce útil para Revenue Operations, e é por isso que ativar cada novidade isoladamente vai entregar menos do que redesenhar o fluxo de decisão entre elas.
Por onde começar a ativação, passo a passo
Você precisa de uma org Winter '27 (API 68.0) com licenças de Revenue Cloud, Billing, Agentforce e Dynamic Revenue Orchestrator ativas, além de acesso ao Setup como admin. Este recurso está em preview: nomes de campo e etapas de ativação podem mudar até a disponibilidade geral.
- No Quick Find do Setup, procure
Salesforce Goe abra o hub central de descoberta e configuração do Revenue Management. - Localize o card Agentforce for Revenue e o card Revenue Cloud; confirme que ambos aparecem antes de prosseguir, porque eles concentram as trilhas de ativação por capacidade.
- Abra a trilha Agentforce for Revenue e acompanhe o status In Progress; na org de teste a página detalhada carregou parcialmente com texto de template, então valide o conteúdo antes de seguir instruções da tela.
- Use o Go para revisar as dependências de licença de cada capacidade (Billing, Promotions, Dynamic Revenue Orchestrator) antes de habilitar qualquer uma, já que o Go torna essas dependências explícitas.
- Configure Billing pelas etapas guiadas do Go: Invoice Management, Tax Calculation, Invoice Document Delivery e Accounting Sub-Ledger, seguindo vídeos e recursos de ajuda indicados.
- Aplique o template pré-construído de orquestração de pedidos de alta tecnologia oferecido no Go para acelerar o setup do Dynamic Revenue Orchestrator em cenários comuns.
- No Object Manager, confira se os objetos de Promotion, ApprovalSubmission e Billing* já existem na org, sinal de que as licenças correspondentes foram provisionadas corretamente.
Como saber que funcionou: o Salesforce Go exibe os cards Agentforce for Revenue e Revenue Cloud agrupados por capacidade, a trilha específica aparece com status atualizado (mesmo que o preview do template ainda mostre inconsistências pontuais), e o Object Manager já lista os objetos de Promotion, Approval e Billing correspondentes às licenças habilitadas na org de pré-release.
Licenças, quebras e o que já é obrigatório
Além do que já é conhecido sobre Winter '27, o texto oficial das release notes traz pontos operacionais que exigem atenção imediata de quem administra a org.
- O template de orquestração para cenários de pedido de alta tecnologia, acessível via
Salesforce Go, exige licençaRevenue Cloud AdvancedouRevenue Cloud Billing. Sem uma dessas, a trilha nem aparece como opção configurável. - O recurso
Invoice Document Deliverysó está disponível com licençaRevenue Cloud Billing. Já oAccounting Sub-Ledger for Accounts Receivablestem apenas parte de suas funcionalidades incluídas na licençaRevenue Cloud Advanced, o que gera confusão em orgs que assumem cobertura completa. - As definições de
Data Processing Engine (DPE)versão 3 usadas em Usage Management deixam de ser suportadas. Flows sobrescritos que ainda referenciam definições v3 não podem mais ser abertos, editados ou executados. É preciso migrar para definições versão 4 antes que o fluxo pare de funcionar. - Os campos
UsageResourceBillingPolicyemUsageResource, os camposUsageResourceeProductemRatingFrequencyPolicy, e o campoOverageChargeableemProductUsageGrantsão removidos na API 67.0. Integrações que ainda apontam para esses campos falham silenciosamente até serem migradas paraProductUsageResourcePolicy,UsageResourcePolicyouUsageOveragePolicy, conforme o caso. - O release update
Optimize Performance for Revenue Managementjá está disponível a partir da Winter '27 como opt-in, com suporte a test run em sandbox. A aplicação passa a ser obrigatória na Summer '27, exigindo licençaRevenue Cloud GrowthouRevenue Cloud Advanced. O comportamento funcional do Configuration API não muda, apenas a performance, mas convém validar em sandbox antes da data de enforcement, disponível no Trust Status na aba de manutenção da instância.
Fontes oficiais
Isso importa porque muda o critério de decisão em arquitetura de receita. Durante anos o padrão de mercado foi tratar CPQ, billing e gestão de contratos como domínios separados, cada um com seu roadmap, seu time e sua integração via API ou middleware. Com Revenue Cloud virando Agentforce Revenue Management, essa fragmentação passa a ser uma escolha cara, não uma consequência técnica inevitável.
Para quem arquiteta esse tipo de solução, o ponto central é que a orquestração entre cotação, faturamento e contrato deixa de ser um problema de integração e passa a ser nativo da plataforma. Isso reduz customização, mas também reduz o espaço de manobra para quem já investiu em uma arquitetura desacoplada por convicção ou por necessidade regulatória.
- Times que ainda pensam CPQ e billing como projetos independentes vão precisar revisar a governança do dado de receita como um todo.
- Decisões de customização feitas nos últimos anos podem virar dívida técnica se não forem reavaliadas à luz do novo modelo agentic.
- A promessa de execução autônoma via agente muda o nível de confiança que o arquiteto precisa depositar na consistência dos dados de origem.
Ignorar essa mudança não é neutro. É continuar otimizando módulos isolados enquanto o resto do mercado está desenhando o motor de receita como um sistema único de decisão.
Renomear produto não é feature, é declaração de arquitetura. Quando a Salesforce decide que Revenue Cloud passa a se chamar Agentforce Revenue Management, ela não está mexendo em branding por vaidade, está dizendo em voz alta que o motor de receita não será mais operado por humano clicando em tela. Vai ser operado por agente, com humano no loop quando muito.
Isso muda a forma como eu penso a implementação desde o dia zero. Não dá mais para tratar CPQ, billing e o resto da suíte como módulos que se conversam via automação tradicional. Se a proposta de valor agora é agente orquestrando cotação, contrato e faturamento, o desenho de dados e de permissão precisa ser pensado para consumo por IA, não só para tela de usuário. Isso é outro nível de rigor em modelo de objeto e em governança de ação.
Fico com um pé atrás na maturidade real disso em Winter '27. Rebrand chega rápido, confiabilidade operacional em ambiente de receita crítica leva mais tempo para provar. Vou testar em sandbox antes de recomendar isso como caminho padrão para cliente com volume sério de faturamento.
Dito isso, a direção estratégica está correta. Quem constrói Revenue Cloud hoje sem pensar em superfície de agente está construindo dívida técnica com prazo de validade curto.
Comece mapeando licenças e permission sets por capacidade antes de habilitar qualquer coisa. Use o Salesforce Go como inventário de dependências, não como wizard mágico.
É pré-release. Nomes de interface, licenciamento e disponibilidade geral ainda podem mudar. Decisão de compra deve se basear em funcionalidade GA.