Fórmulas reativas agora funcionam em regras de visibilidade condicional
Telas de Flow ganham suporte oficial para referenciar fórmulas reativas em condições de exibição de componentes.
Eu vejo essa mudança como um ajuste que deveria ter existido desde o lançamento de fórmulas reativas. Agora consigo referenciar uma fórmula reativa direto numa regra de visibilidade condicional, sem precisar de gambiarras com variáveis auxiliares.
O que é
A partir da Winter '27, é possível referenciar fórmulas reativas diretamente em regras de visibilidade condicional de telas de Flow. Segundo as release notes, fórmulas reativas agora avaliam corretamente dentro das regras de conditional visibility, permitindo construir experiências de tela mais responsivas.
Antes dessa mudança, a visibilidade condicional não suportava referenciar fórmulas que incluíssem componentes presentes na mesma tela. Ou seja, se a fórmula reativa dependia de um campo ou componente daquela própria tela, a condição de visibilidade não conseguia usar essa fórmula como critério.
O texto oficial não detalha requisitos adicionais de API version ou de ativação, então entendo que o comportamento passa a valer nativamente para quem já usa fórmulas reativas em telas de Flow.
Por que importa
Essa limitação sempre foi um ponto de atrito real. Eu já perdi tempo em projetos tentando montar visibilidade condicional que dependia de um valor calculado na própria tela, e a saída era criar uma fórmula reativa separada só para exibir o valor, e uma variável de tela paralela para servir de gatilho da condição. Funcionava, mas duplicava lógica e deixava o Flow mais difícil de manter.
Com o suporte direto, a lógica de exibição fica mais enxuta e mais próxima do que o usuário realmente vê na tela. Isso é especialmente relevante em telas com múltiplos componentes interdependentes, onde a reatividade precisa refletir mudanças em tempo real sem postback ao servidor. Do ponto de vista de arquitetura, é um ganho de manutenibilidade. Menos componentes ocultos usados só como intermediários de lógica, menos pontos de falha para debugar quando a visibilidade não se comporta como esperado.
Como se preparar
- Revise Flows existentes que usam fórmulas reativas com componentes auxiliares ocultos criados só para contornar essa limitação, e avalie simplificar a lógica de visibilidade condicional diretamente com a fórmula reativa original.
- Ao construir novas telas, teste a visibilidade condicional referenciando a fórmula reativa antes de criar qualquer variável intermediária, já que isso pode não ser mais necessário.
- Documente nos seus Flows quais componentes dependem de fórmulas reativas para visibilidade, facilitando a manutenção por outros membros da equipe.
- Valide o comportamento em ambiente de sandbox antes de aplicar em produção, principalmente em telas complexas com várias camadas de condições aninhadas.
Nível de aplicação: Baixo
É uma melhoria nativa de comportamento em telas de Flow, sem necessidade de habilitação ou configuração adicional, apenas ajuste de lógica existente.
Considerações de arquiteto
- Antes de simplificar Flows legados, mapeie todos os componentes ocultos criados como workaround para não remover algo que ainda tenha outra dependência funcional.
- Teste a reatividade em telas com múltiplos componentes interdependentes, pois o comportamento de recálculo em tempo real pode variar conforme a ordem de avaliação das fórmulas.
- Considere o impacto em Flows que já estão em produção e amplamente utilizados, priorizando a refatoração primeiro em ambientes de menor criticidade.
- Avalie se a simplificação da lógica de visibilidade afeta testes automatizados ou validações que dependiam da estrutura anterior com variáveis intermediárias.
Pegadinhas:
- As release notes não detalham requisitos de API version, então vale confirmar na sua org se o comportamento já está ativo antes de remover os workarounds antigos.
Este artigo faz parte do guia Flow na Winter '27, um item oficial por artigo. Fonte: release notes de Automation.