Cotações de 15 mil linhas: o número é real, a meta de design não é
O teto de grandes transações sobe, mas capacidade máxima anunciada não é alvo de arquitetura.
Pricing, regras de configuração, transformação de contexto e geração de documentos passam a suportar até 15 mil linhas. O número aproxima Revenue Management de telecom, high tech e manufatura. O ganho real depende de desenho de regras e estratégia assíncrona, não do endpoint.
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.
Quando uma release anuncia “até 15 mil linhas”, existe um risco previsível: alguém transforma o teto em requisito. Deixo o aviso logo no começo: 15 mil linhas é capacidade máxima anunciada, não meta de design de toda cotação.
O que mudou
A release amplia a operação de grandes transações em quatro frentes que antes tinham tetos diferentes: pricing, regras de configuração, transformação de contexto e geração de documentos. Além do volume:
- A sincronização de cotações grandes com oportunidades pode ocorrer sem bloquear o usuário.
- Há recuperação de erros em vez de falha total do lote.
- A reutilização automática de contexto reduz processamento redundante.
Esse terceiro ponto é o mais subestimado. Em cotações grandes, boa parte do custo não está no cálculo, está em remontar contexto a cada iteração.
Por que importa
O teto aproxima Revenue Management de cenários em que bundles, sites, rampas e itens de consumo multiplicam o volume: telecom, high tech, manufatura e serviços complexos. São exatamente os setores em que o CPQ clássico quebrava e o cliente terminava com uma planilha paralela.
Como eu testaria antes de prometer
- Teste em conjunto, não em partes. Pricing, configuração, documento e sync precisam ser medidos juntos. Um elo rápido não compensa outro saturado.
- Cenários progressivos. 5 mil, 10 mil e 15 mil linhas, a curva importa mais que o pico.
- Meça a experiência, não só o throughput. Tempo total, retries, volume de contexto e o que o vendedor sente na tela.
O que eu não consegui verificar
Sendo direto: as release notes classificam as capacidades de grandes transações como dependentes de setup do administrador. Na minha org de teste, vazia, sem massa transacional, consegui confirmar objetos e permissões, mas não executar um benchmark real de 15 mil linhas. Qualquer número de performance que você ler por aí sem teste funcional atrás é especulação.
Como preparar a org para cotações grandes, passo a passo
Pré-requisitos: org de pré-release Winter '27 com Agentforce Revenue Management habilitado, acesso ao Setup com Salesforce Go e perfil de administrador. Na minha org, os apps Product Catalog Management e Price Management já vinham provisionados; em org nova, confirme antes de avançar.
- Confira as release notes em preview. Abra a seção Large Transactions and Quote Processing nas release notes oficiais antes de configurar qualquer coisa, porque a Salesforce deixa explícito que os recursos podem mudar até a disponibilidade geral.
- Use o Salesforce Go no Setup. No Quick Find do Setup, procure Salesforce Go e localize os cards Agentforce for Revenue e Revenue Cloud, porque é ali que a release concentra descoberta e ativação guiada dessas capacidades.
- Habilite a sincronização assíncrona em Revenue Settings. No Quick Find do Setup, procure Revenue Settings e ative a opção de sincronizar cotações grandes com oportunidades, porque o texto oficial é claro: essa capacidade precisa ser habilitada tanto para cotações padrão quanto para as grandes.
- Valide as pricing procedures separadas. No app Price Management, abra Pricing Procedures e confirme se existe (ou crie) uma procedure dedicada a transações grandes, porque a release recomenda separar a lógica de precificação quando o volume de linhas exige comportamento diferente do padrão.
- Não configure o context reuse manualmente. Verifique no Object Manager os objetos ligados a Context Service, mas não procure um toggle para reutilização de contexto, porque a documentação afirma que esse recurso é habilitado automaticamente para transações grandes, sem etapa de setup.
- Prepare a geração de documentos para hierarquias grandes. Confirme no CLM Document Generation se os templates suportam bundles aninhados, porque o teto anunciado de 15 mil linhas vem junto com limites específicos de 1.000 bundles e 5 níveis de agrupamento.
- Trate erros de cálculo como parte do fluxo, não como exceção. Identifique o endpoint REST indicado nas release notes para alterar manualmente estados de cálculo travados para Failed, porque isso é o mecanismo oficial de recuperação em lotes grandes, e não um ajuste de UI.
- Teste em conjunto, nunca em partes isoladas. Monte um cenário progressivo com 5 mil, 10 mil e 15 mil linhas cobrindo pricing, configuração, documento e sync na mesma execução, porque um elo rápido isolado não revela gargalo em outro ponto da cadeia.
Como saber que funcionou: a sincronização da cotação grande com a oportunidade deve rodar em background sem travar a tela do vendedor, o Reprice All no editor de Transaction Management deve concluir sem timeout mesmo com milhares de linhas, e uma falha pontual de cálculo deve aparecer como estado recuperável via API, não como falha total do lote. Sendo direto, na minha org de pré-release, vazia e sem massa transacional, só consegui confirmar objetos e permissões, não um benchmark real nas 15 mil linhas.
O que ligar antes e o que pode quebrar
Antes de testar qualquer cenário de 15 mil linhas, confira dois toggles em Revenue Settings. O primeiro é Asynchronous Opportunity Sync, que precisa estar ativo tanto para cotações padrão quanto para grandes cotações antes de qualquer sync entre quote e oportunidade. O segundo é Large Transaction Processing, exigido para os algoritmos de lote melhorados e para o suporte a itens de linha aninhados. Sem os dois ligados, o comportamento de grandes transações simplesmente não aparece na org, e o teste vira ruído.
Ligado o toggle, falta a permissão. O texto oficial é explícito: usar essa capacidade exige a permissão Large Transaction atribuída ao usuário, não basta o toggle de org estar ativo.
Duas peças de automação mudam de comportamento sem aviso visual na UI.
- A nova invocable action
syncQuoteOpportunitysincroniza quote line items para opportunity line items em uma via só. Mudança em quote line item atualiza o opportunity line item correspondente, mas o inverso não acontece. Se algum flow espera propagação nos dois sentidos, ele quebra silenciosamente. - Para usar essa invocable action em um
Flow Approval Processou qualquer outra automação, oAsynchronous Opportunity Syncprecisa estar ligado emRevenue Settings. Sem isso, a action fica disponível no flow mas não executa o sync esperado.
Se um cálculo travar em transação grande, a Connect REST API agora permite mover o estado preso para Failed manualmente, via recurso /connect/revenue/transaction-management/sales-transactions/actions/read com os novos parâmetros shouldReturnMetadataOnly e batchIndices. É a via de retry rápido quando o batch não recupera sozinho.
Pricing procedure separada para transações grandes não é automática. É preciso configurar explicitamente uma pricing procedure distinta quando a transação grande exige capacidades de pricing diferentes da padrão, o motor não infere isso sozinho.
Todas essas capacidades exigem licença Revenue Cloud Growth ou Revenue Cloud Advanced em edição Enterprise, Unlimited ou Developer. Confirme a licença antes de procurar o toggle, porque ele simplesmente não aparece sem ela.
Fontes oficiais
Um número de capacidade máxima em release notes é fácil de confundir com meta de performance. Não é. Suportar 15 mil linhas em uma cotação significa que o sistema não trava nesse patamar, não que qualquer arquitetura chegue lá com a experiência que o negócio espera.
Para quem desenha soluções de Revenue Cloud em telecom, high tech e manufatura, essa distinção decide o projeto. São segmentos onde bundles complexos e catálogos profundos empurram o volume de linhas para cima com facilidade, e onde a tentação de tratar o teto anunciado como sinal verde para qualquer modelo de dados é real.
- Processamento assíncrono deixa de ser otimização e vira pré-requisito de design em volumes altos.
- Seletividade de contexto, ou seja, carregar e recalcular só o que mudou, é o que evita que pricing e regras de configuração se tornem o gargalo.
- Ignorar essas duas frentes e confiar apenas no limite do release note é o caminho mais curto para um problema de performance em produção, meses depois do go-live.
Arquiteto que trata capacidade máxima como sinônimo de arquitetura pronta está terceirizando uma decisão técnica para uma nota de release. O trabalho continua sendo modelar fluxo de dados, definir onde processar de forma síncrona e onde empurrar para background, e testar sob carga real antes de assumir que o teto se aplica ao seu caso.
15 mil linhas por transação é o tipo de número que vira manchete e esconde a pergunta certa. A pergunta não é "quantas linhas o sistema aguenta", é "quantas linhas o seu modelo de dados aguenta sem degradar regras de preço, triggers e automações que você empilhou nos últimos três anos".
Todo aumento de teto na plataforma tem esse efeito colateral: ele é lido como convite. Alguém no negócio vê o número novo e assume que a arquitetura foi validada para operar naquele patamar como rotina. Não foi. Capacidade máxima é o limite que a engenharia da Salesforce testou para não quebrar o sistema. Não é a meta de performance que você deveria projetar para o seu produto.
Isso importa especialmente em Revenue Cloud e CPQ, onde é comum ver bundle nested, regras de configuração encadeadas e price rules disparando em cascata. Cada uma dessas camadas tem custo computacional que cresce de forma não linear com o volume de linhas. Rodar um teste de carga em 15 mil linhas com automação real ligada é uma experiência bem diferente de ler o número no release note.
Minha regra de arquitetura aqui é simples: teto anunciado define o que é tecnicamente possível, não o que é operacionalmente saudável. Se o seu design de solução depende de operar perto do limite máximo para funcionar, o problema não é o limite. É o design.
O que eu costumo fazer é o oposto do que a notícia sugere: uso o anúncio como gatilho para revisitar meus SLAs internos de tamanho de transação, não para relaxá-los. Se hoje minha meta de arquitetura é performance estável até 2 ou 3 mil linhas, o novo teto não muda essa meta. Só me dá mais margem de segurança para os picos que eu não previ.
O número de 15 mil linhas é um limite testado pela engenharia da Salesforce em condições controladas. Não é uma promessa de que sua org vai performar bem nesse volume, e tratar isso como meta de arquitetura é o primeiro erro que eu vejo em projetos de Revenue Cloud e CPQ.
Na prática, o trabalho do arquiteto começa antes de qualquer teste de carga:
- Mapeie o volume real de uso: puxe dados históricos de cotações do cliente. Se 95% delas têm menos de 500 linhas, otimizar para 15 mil é esforço mal direcionado. Dimensione para o p95 do negócio, não para o teto do produto.
- Rode testes progressivos: monte cenários de 1k, 5k, 10k e 15k linhas medindo pricing, geração de documento, configuração de produto e sincronização em conjunto, não isoladamente. É a combinação desses processos rodando junto que derruba performance em produção.
- Instrumente observabilidade ponta a ponta: sem visibilidade de tempo de resposta em cada etapa (regras de preço, callouts, triggers, flows), você não vai saber onde está o gargalo quando o volume crescer. Configure isso antes de escalar, não depois do incidente.
- Isole a lógica customizada: regras de pricing customizadas, validações e automações são normalmente o gargalo real, não o motor nativo do Revenue Cloud. Audite o que roda por linha de cotação e questione cada peça que não é essencial.
- Documente o limite prático da sua org: depois dos testes, registre qual é o volume que sua implementação suporta com performance aceitável. Esse número, e não o do release notes, deve orientar decisões de produto e expectativa do time de vendas.
Arquitetura não se faz mirando na capacidade máxima anunciada. Se faz entendendo o comportamento real da sua solução sob a carga que o negócio de fato gera.
- 15 mil linhas é teto de laboratório, não é SLA. Ninguém garante esse número na sua org com suas customizações, seus triggers e seu volume de regras de preço.
- Capacidade máxima depende de setup do administrador. Se o time não configurar corretamente batch processing, índices e lazy loading, o comportamento em produção não chega nem perto do anunciado.
- Automação síncrona em objetos de linha de cotação é o jeito mais rápido de destruir qualquer ganho de performance. Trigger mal escrito em Quote Line Item não fica mais rápido só porque a plataforma aguenta mais linhas.
- Regras de preço complexas, price rules aninhadas e lookups cruzados escalam pior que o volume de linhas em si. O gargalo raramente é a quantidade, é a lógica em cima da quantidade.
- Times de projeto costumam usar o número da release como justificativa para não revisitar arquitetura de dados existente. Isso é dívida técnica sendo empurrada com a barriga.
- Teste de carga com dado sintético não reproduz comportamento real. Sem volume de produção, histórico de customização e concorrência de usuários, a validação é decorativa.
- Aumento de teto não resolve UX. Usuário abrindo cotação de 15 mil linhas em tela ainda é experiência ruim, independente do backend aguentar.