Resumo da Semana, Salesforce reorganiza a plataforma em torno de headless e o Flow vira engenharia de verdade
Winter '27 traz maturidade de engenharia ao Flow enquanto a arquitetura headless via MCP redefine como agentes e UI consomem capacidades da plataforma.
A semana não trouxe bombshells, mas revelou uma mudança de gramática de plataforma: Salesforce se reorganiza em torno de MCP, expondo cada cloud como capacidade descobrível por agentes, enquanto o Flow finalmente ganha tratamento de código com testes, versionamento e um canvas mais denso. Arquitetos precisam repensar governança de permissão para agentes e revisar release updates antes que integrações legadas quebrem silenciosamente.
Semana de release, não de bombshell. Winter '27 documentou notas, Salesforce Ben publicou os "top N" de praxe por nuvem, e no meio disso o material mais denso da semana veio, ironicamente, de dentro de casa: os posts da série sobre Revenue Cloud e a leitura sobre headless architecture. Nada explosivo, mas há pelo menos três coisas que valem sua atenção de arquiteto, e uma quarta que é mais estratégica do que técnica.
Headless 360: o Salesforce parando de ser um app e virando um barramento de capacidades
Fonte: Salesforce News & Insights | Complementar: What is Headless Architecture
Esse é o destaque real da semana, mesmo sem vir empacotado como feature de release note. A Salesforce está reorganizando a plataforma inteira em torno de MCP, cada cloud (Sales, Service, Data, Commerce) exposta como capacidade descobrível e acionável por qualquer agente autorizado, não só pela UI clicável que conhecemos há vinte anos. Isso não é mais discurso de commerce headless empacotado de novo com verniz de IA; é uma mudança de gramática de plataforma.
Na prática, isso muda o que você desenha primeiro num projeto. Hoje o arquiteto ainda pensa "página, layout, fluxo, depois talvez uma API". Nesse modelo, a ordem se inverte: você desenha a capacidade, o que um agente pode pedir, com que contexto, sob que permissão, e a UI vira só mais um consumidor daquilo, igual a um agente seria. Permissionamento deixa de ser "quem pode ver este campo" e passa a ser "que ferramenta este agente pode invocar, em nome de quem, com que escopo de dados".
O ponto de atenção prático: isso empurra governança de agente para o mesmo nível de maturidade que hoje tratamos sharing rules e field-level security. Se sua org ainda trata perfil e permission set como planilha esquecida, você não está pronto para esse mundo, e a lacuna vai aparecer rápido quando o primeiro agente Agentforce começar a descobrir capacidades que ninguém revisou.
Winter '27 e o Flow: virou engenharia, e isso tem um preço em quebra de compatibilidade
Fonte placeholder, release notes oficiais
A Winter '27 é, sem exagero, o maior pacote de evolução do Flow desde a unificação com Process Builder. Test Mode nativo, histórico por versão, tags, Screen Flow rodando dentro de ações em massa, isso é Salesforce reconhecendo, com quatro anos de atraso, que Flow é código e precisa ser tratado como código: testável, versionado, rastreável. Quem construiu automação crítica de negócio em Flow nos últimos anos sabe o custo de não ter isso; agora vem embutido.
O canvas mais denso é um detalhe que parece cosmético e não é. Cards menores, menos arredondados, opção de esconder API names e recolher labels, para quem administra flow de 20 elementos isso não importa nada. Para quem vive em flows de 60, 80 elementos (e no Revenue Cloud isso é regra, não exceção), é a primeira mudança de UI em anos que ataca o problema de verdade, que é espaço de tela e legibilidade, não estética.
O outro lado da moeda, que pouca gente está comentando com o peso devido: o pacote de release updates enforçados nessa mesma release pode quebrar integração legada silenciosamente. Não é o tipo de coisa que aparece no changelog bonito, aparece no chamado de suporte em outubro, quando alguém percebe que um fluxo parou de disparar. Se você administra org com automação antiga, essa é a semana de rodar o Release Updates dashboard, não a semana de ler resumo de feature nova e seguir em frente.
CPQ acabou? A pergunta certa não é "quando a Salesforce descontinua", é "o que a sua org já está sinalizando"
Post da série sobre Revenue Cloud, sem link externo, conteúdo autoral publicado nesta semana.
Tenho visto gente decidir migração de CPQ para Revenue Cloud pelo calendário de EOL da Salesforce, e isso é o critério errado. CPQ segue rodando, seguirá rodando por anos, e "vai ser descontinuado" não é argumento de arquitetura, é argumento de vendas. O argumento de arquitetura é outro: CPQ virou uma plataforma sem investimento de produto. Toda energia de engenharia da Salesforce em pricing, bundling e billing está indo para o Revenue Cloud. Isso significa que todo problema novo que aparecer na sua operação comercial daqui pra frente vai ter solução no Revenue Cloud e gambiarra no CPQ.
Os sinais que valem mais que o hype: sua equipe está criando price rules cada vez mais complexas para simular comportamento que o Revenue Cloud já resolve nativo? Você tem múltiplos objetos custom tentando emular Bundle e Selling Model porque o catálogo do CPQ não aguenta a complexidade do seu portfólio? Você já tem Billing rodando separado e sofre com reconciliação manual entre CPQ e financeiro? Cada "sim" aqui é peso real na balança, mais real que qualquer data de fim de suporte.
O roteiro que defendo é decidir com número: quanto custa manter o time construindo workaround em CPQ pelos próximos 18 meses versus o custo de uma migração planejada. Quando ainda não vale migrar: catálogo simples, sem bundle complexo, sem plano de crescer international pricing ou usage-based billing. Migração de Revenue Cloud não é projeto de "modernização", é projeto de fundação, e fundação errada custa caro de desfazer depois.
Product Catalog Management: o catálogo como fonte única da verdade
Post da série sobre Revenue Cloud, sem link externo, conteúdo autoral publicado nesta semana.
Esse post fecha um buraco que a documentação oficial da Salesforce deixa aberto: ninguém explica direito por que a hierarquia Catalog → Category → Product2 existe e o que ela resolve que o catálogo legado do CPQ não resolvia. A resposta curta é governança de dados de produto em escala, quando você tem múltiplas linhas de negócio, múltiplas moedas, múltiplos canais de venda, o catálogo legado vira uma colcha de retalhos de campos custom e regras de validação que só o time de CPQ entende.
O ponto mais útil pra quem está desenhando um catálogo novo é a distinção entre Simple vs Bundled e Static vs Configurable, essa matriz de quatro quadrantes decide praticamente toda a complexidade de configuração daqui pra frente. Um produto Simple e Static é decisão trivial; um produto Bundled e Configurable exige que você entenda os limites de bundle antes de desenhar, não depois. Já vi implementação estourar limite de bundle na primeira UAT porque ninguém leu a doc de limites antes de modelar o catálogo.
O detalhe que separa quem entende Revenue Cloud de quem só decorou os objetos: Classifications não é campo custom disfarçado, é a forma de tornar atributo reutilizável entre produtos sem duplicar metadado. Se você está migrando de CPQ e replicando a mesma estrutura de atributo por produto que tinha lá, está perdendo o principal ganho estrutural do PCM.
Da Quote à Order: onde nasce o Asset e por que isso muda o pós-venda
Post da série sobre Revenue Cloud, sem link externo, conteúdo autoral publicado nesta semana.
Esse é o post mais "arquitetura pura" da série, e o que mais recebo pergunta sobre em projeto real: por que existem dois caminhos até a Order, e por que isso importa. B2C direto e B2B com aprovação não são só workflow diferente, são dois desenhos de dados diferentes, com pré-requisitos de configuração distintos para o Create Order sequer funcionar. Time que ignora isso descobre o problema em produção, não em sandbox.
O ponto que mais gera retrabalho em migração é decidir quando dividir uma Quote em múltiplas Orders. Não é decisão de UI, é decisão de billing e de reconhecimento de receita, se você tem produtos com datas de ativação diferentes ou centros de custo diferentes, ignorar isso na Quote significa reconciliar manualmente depois, e "depois" nesse caso é o financeiro batendo na sua porta.
O fechamento do post é o que fica: ativação transforma Order Product em Asset na Account, e é esse Asset que vira a base de todo o pós-venda, renovação, upsell, suporte. Quem desenha a Order sem pensar no Asset que ela vai gerar está resolvendo só metade do problema. Revenue Cloud te força a pensar no ciclo de vida completo desde a Quote; CPQ deixava isso para depois, e "depois" é exatamente onde a dívida técnica se acumula.
Menções rápidas
- Rohan Kumar assume discurso de adoção antes de feature, carta ao ecossistema dizendo que "cliente quer resultado, não feature de IA". Vale acompanhar se isso muda o ritmo de lançamento do Agentforce ou é só retórica de novo cargo. Salesforce Ben
- Slack Code, vibe-coding dentro do Slack, agentes e humanos no mesmo canal escrevendo e revisando código. Interessante como sinal de direção, ainda cedo para avaliar impacto real em projeto Salesforce. Salesforce News
- Why AI-Generated Code Is Easy but Engineering Trust Is Hard, bom texto sobre o risco de PR gigante gerado por agente com erro de interpretação enterrado no meio. Leitura recomendada para quem já está deixando agente commitar Apex. Salesforce Engineering Blog
- Open Semantic Interchange vira Apache Ossie, movimento de padronização semântica de dados ganhando tração fora do guarda-chuva só-Salesforce, com 50+ parceiros. Vale monitorar se isso afeta modelagem no Data Cloud. Salesforce Blog
- Os "Top N" de Winter '27 por nuvem (developers, admins, Service Cloud, Sales Cloud) do Salesforce Ben são úteis como checklist, não como análise, recomendo como referência de leitura rápida antes de planejar upgrade de sandbox. Developers | Admins | Service Cloud | Sales Cloud
O que observar na semana que vem
Fica de olho em duas frentes. Primeiro, se o discurso de Rohan Kumar sobre "adoção antes de feature" vira algo concreto no roadmap ou fica só em carta, isso importa para quem planeja investimento em Agentforce nos próximos trimestres. Segundo, com Dreamforce se aproximando, espero começar a ver vazamento de conteúdo de keynote e sessão técnica; vale acompanhar principalmente qualquer coisa nova sobre Data Cloud e MCP, porque é ali que a história do headless 360 desta semana deve ganhar mais carne. Semana tranquila em volume, mas com pelo menos duas sementes, headless como arquitetura padrão e Flow tratado como engenharia, que vão dar fruto nos próximos meses.
Winter '27 marca uma virada de eixo na plataforma, e quem trabalha com arquitetura precisa entender isso rápido para não ficar desenhando soluções para um Salesforce que já não existe mais do mesmo jeito.
O Flow deixando de ser ferramenta de automação pontual para virar peça de engenharia de verdade muda a conversa com o cliente e com o time de desenvolvimento. Não é mais sobre "o admin resolve no Flow ou o dev resolve no Apex". É sobre onde cada lógica de negócio deve viver dentro de um ciclo de vida de software que agora exige versionamento, teste e observabilidade sérios, independente de quem construiu.
Já a arquitetura headless via MCP redefine algo mais estrutural ainda: como agentes e interfaces consomem capacidades da plataforma. Isso não é só uma camada de API nova. É a Salesforce assumindo que UI e lógica de negócio precisam se desacoplar de verdade para que Agentforce e qualquer outro consumidor externo funcionem sem ficar refém de como a tela foi desenhada.
Para arquitetos, isso importa por três motivos práticos:
- Decisões de design que pareciam definitivas há dois anos (onde colocar lógica, como expor dados, que camada é dona de qual regra) precisam ser revisitadas com essa nova realidade em mente.
- Revenue Cloud e Agentforce só entregam o prometido se a base arquitetural (Flow maduro, dados expostos de forma headless) estiver pronta. Sem isso, é só marketing rodando em cima de gambiarra.
- Quem não acompanhar essa reorganização vai continuar propondo arquiteturas de 2022 para problemas de 2027, e isso custa caro em retrabalho e em credibilidade técnica.
Não é hype. É a plataforma se preparando estruturalmente para um mundo onde agente, humano e integração externa consomem a mesma capacidade de negócio, só que por portas diferentes.
O que me chama atenção nessa leva do Winter '27 não é nenhuma feature isolada, é a direção. A Salesforce está admitindo, na prática, que Flow precisa se comportar como código: versionamento sério, testes, rastreabilidade de execução. Quem já apanhou em produção com um Flow gigante e sem visibilidade nenhuma sabe o tamanho do alívio disso. Não resolve tudo, mas é a plataforma reconhecendo que declarativo em escala tem as mesmas dores de engenharia que qualquer outro código, só que estavam escondidas atrás do discurso de "low-code para todos".
A parte mais estrutural, pra mim, é o MCP. Isso muda a pergunta que a gente faz em arquitetura. Antes era "como exponho essa capacidade via API ou via componente Lightning". Agora é "como essa capacidade fica acessível para um agente consumir sem UI nenhuma no meio". Parece sutil, mas redesenha decisões de camada de serviço, contrato de dados e até governança de permissão. Projeto que for pensado só para tela vai nascer capenga para o mundo de agentes que já está batendo na porta.
Minha leitura prática: quem trabalha com Flow Builder hoje precisa parar de tratar isso como ferramenta de automação pontual e começar a tratar como componente de arquitetura, com os mesmos cuidados de nomenclatura, modularização e teste que qualquer integração crítica exige. E quem está desenhando solução nova já deveria estar perguntando se aquela capacidade de negócio vai precisar ser consumida por um agente também, não só por um humano clicando em botão.
Se você é arquiteto e ainda está tratando essas mudanças como "novidade de release notes", pare. Isso aqui é reposicionamento de plataforma. Trate como tal.
- Audite seus Flows críticos com lente de engenharia. Pegue os três ou quatro Flows mais complexos do seu org (aqueles que ninguém quer mexer) e avalie onde a maturidade nova do Flow Builder resolve dívida técnica real: modularização, tratamento de erro, testabilidade. Não é sobre adotar recurso novo por adotar.
- Mapeie onde MCP entra na sua arquitetura de integração. Antes de sair conectando agentes a tudo, desenhe o inventário de capacidades que fazem sentido expor via headless. Pergunta certa: essa capacidade precisa ser consumida por múltiplos canais (UI, agente, API externa) ou é acoplamento desnecessário se você abstrair agora?
- Revise a fronteira entre Flow e Apex no seu time. Com o Flow ganhando robustez de engenharia de verdade, a decisão "quando sair do Flow e ir pro Apex" muda de critério. Documente esse critério atualizado para o time, porque decisão tomada há dois anos com base em limitação antiga do Flow pode estar obsoleta.
- Se você trabalha com Revenue Cloud, valide o alinhamento com a arquitetura headless. Capacidades de billing e pricing expostas via MCP mudam como você desenha extensibilidade para agentes de vendas. Não assuma que o modelo de integração atual do seu Revenue Cloud aguenta esse novo padrão de consumo sem ajuste.
- Rode um piloto pequeno de Agentforce consumindo capacidade via MCP. Escolha um caso de uso de baixo risco, meça latência e comportamento, e use isso como base de decisão antes de prometer para o negócio algo em escala maior.
O ponto central é simples: quem tratar isso como atualização incremental vai se atrapalhar em seis meses quando o resto do ecossistema já estiver desenhando em cima dessa arquitetura headless como padrão, não como exceção.
- Governança de MCP ainda é ponto cego. Quem expõe capacidades headless precisa definir controle de acesso, versionamento e auditoria antes de sair habilitando agentes para consumir tudo que a org tem.
- Flow com engenharia de verdade significa que os erros de arquitetura também viram erros de verdade. Times acostumados a montar automação sem disciplina de teste vão sofrer quando o Flow passar a se comportar como código.
- Migrar lógica existente para o novo modelo não é automático. Quem tem Flows legados construídos sem padrão vai precisar de um trabalho real de refatoração, não só de "ativar a feature nova".
- Headless via MCP muda a superfície de ataque. Cada capability exposta é um ponto a mais de integração e de risco de segurança, e isso exige revisão de shield, permission sets e políticas de dados antes de qualquer rollout.
- Revenue Cloud entrando nesse ecossistema headless aumenta a complexidade de orquestração entre CPQ, billing e agentes consumindo dados de pricing em tempo real. Testar isso em sandbox superficial é receita para incidente em produção.
- Agentforce consumindo capacidades via MCP exige clareza sobre quem é o dono da lógica de negócio. Se o agente decide e o Flow executa, alguém precisa modelar essa fronteira com cuidado, porque debugar decisão de agente é bem diferente de debugar automação declarativa.
- Adoção prematura sem entender o ciclo de maturidade do Winter '27 é o erro mais comum que vou ver nos próximos meses. Empolgação com feature nova sem avaliar impacto em governança de release é o tipo de decisão que gera dívida técnica cara depois.