Flow Builder mais denso no Winter '27: quando o canvas finalmente pensa em quem vive dentro dele
Novas opções de visualização, cards mais compactos e agrupamento de elementos mudam a forma de trabalhar em flows grandes, mas o custo aparece no treinamento e na documentação da sua base instalada
O Winter '27 traz um canvas mais denso para o Flow Builder: cards menores, menos arredondados, e opções de visualização para esconder API names e recolher labels e descrições. Parece cosmético, mas para quem administra flows de 40, 60, 80 elementos, é a primeira mudança de UI que ataca o problema real: espaço na tela.
Se você já abriu um flow de sessenta elementos e passou mais tempo rolando a tela do que lendo lógica de negócio, sabe exatamente do que estou falando. O Flow Builder sempre teve um problema de densidade: cada elemento ocupava um cartão generoso, com bastante espaço em branco, ótimo para quem está aprendendo, péssimo para quem convive todo dia com automações complexas de verdade.
O Winter '27 ataca isso de frente, e a mudança central é visual, mas com implicação prática séria. Os cards dos elementos ficaram menores e menos arredondados. Isso por si só já libera espaço horizontal no canvas. Mas o ganho de verdade vem de um conjunto novo de opções de visualização, acessível por um ícone no canto superior direito do builder: você pode ocultar API names, recolher labels e descrições, ou escondê-los por completo. Existe hoje uma única aba chamada "General" nesse menu, o que sugere que a Salesforce está deixando espaço para mais controles de exibição em releases futuras.
O que realmente mudou
- Cards mais compactos: menos padding, cantos menos arredondados. Ganho direto de espaço útil na tela, especialmente perceptível em flows com múltiplos branches lado a lado.
- Menu de elementos reorganizado: o botão de "+" não abre mais aquele modal cheio de categorias que você clicava há anos. Agora abre um painel lateral à direita, com elementos agrupados por tipo (Decision Split, Manage Data, Flow Logic, Interaction, Actions) e os mais usados subindo automaticamente para o topo.
- Opções de visualização (ocultar API names, recolher labels/descrições): o ponto que dá nome à mudança. Em um flow denso, você finalmente consegue alternar entre visão detalhada (para debug e documentação) e visão compacta (para navegação rápida).
- Agrupamento de seções (Groups): você pode selecionar um trecho do flow, dar um nome e uma descrição, e recolher aquele bloco inteiro em uma única faixa colapsável. Não é subflow, mas cumpre parte do papel de organização visual que faltava havia anos.
- Color picker customizável em Display Text e Text Template: deixou de ser um conjunto fixo de cores, agora aceita cor customizada.
Esse conjunto todo aponta para uma direção clara: a Salesforce está tratando o Flow Builder como uma ferramenta de produção industrial, não mais como um editor para automações simples. Faz sentido, porque é exatamente isso que ele virou na prática, em qualquer org de porte médio para cima.
Para quem administra orgs com flows grandes, essa é a primeira atualização de UI em anos que ataca o problema de espaço de tela de forma direta, e não com mais um botão perdido em um menu. Times que vivem debugando record-triggered flows com múltiplos decision splits ganham uma ferramenta de leitura mais rápida do fluxo, o que reduz tempo de troubleshooting em incidentes de produção.
O impacto silencioso é outro: nada aqui quebra um flow em execução, é puramente cosmético em termos de runtime. Mas quebra tudo que depende da aparência do builder. Se sua empresa tem runbooks de onboarding com print de tela, documentação de processo interno mostrando "clique aqui, depois aqui", ou treinamento gravado em vídeo, esse material envelhece de uma vez só no fim de semana da atualização.
Baseado nas notas de release oficiais da Salesforce para Winter '27 e em cobertura de pré-release orgs. Como parte das mudanças (Groups colapsáveis, disponibilidade exata de cada view option) foi observada em orgs de preview antes da liberação geral, recomendo validar o comportamento final na sua própria sandbox antes de comunicar para o time.
Antes de tudo, abra uma sandbox ou developer org de preview e navegue por um flow real, de preferência um dos mais complexos que você tem em produção, não um exemplo de laboratório. Teste as opções de ocultar API names e recolher labels: decida como padrão de equipe qual visão fica ativa por default, porque isso influencia como todo mundo vai ler o mesmo flow daqui pra frente.
Depois, refaça qualquer material de treinamento, documentação de arquitetura ou runbook que tenha screenshot do Flow Builder. Não é trabalho glamouroso, mas é o tipo de dívida que se acumula rápido se ninguém tocar no assunto antes do upgrade de produção. Se você usa Groups para organizar flows legados gigantes, aproveite a janela de release para já ir segmentando por contexto de negócio, isso ajuda inclusive quem for revisar o flow com apoio de IA no futuro.
O principal risco aqui não é técnico, é operacional: equipes que documentam processo com base em capturas de tela vão descobrir, no fim de semana da atualização, que boa parte do material ficou desatualizado. Isso vale tanto para documentação de admin interno quanto para conteúdo de treinamento de parceiros e consultorias.
Outro ponto de atenção prático: se sua rotina de suporte ou auditoria depende de ver API names por padrão no canvas (comum em times que fazem code review de flows ou auditoria de nomenclatura), confirme qual é o comportamento default dessa nova opção antes de assumir que nada mudou. E lembre-se que Flow Test Mode ainda é Beta: ótimo para começar a validar cenários de teste em ambiente controlado, mas não é hora de migrar todo seu processo de QA de automação para cima dele.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.