Edit History no Flow: histórico de versões com diff visual
Agora dá para ver exatamente o que mudou entre uma versão e outra de um flow, sem depender de memória ou de comentários no elemento.
O Flow Builder ganhou um histórico de edições que mostra o timeline de saves, o diff das mudanças e permite restaurar ou copiar lógica de versões antigas. Isso resolve um problema real de rastreabilidade que eu enfrentava em quase todo projeto com flows críticos.
O que é
Para flows que suportam versionamento, o Flow Builder agora exibe um timeline com cada save realizado. A partir desse timeline, dá para visualizar o que mudou entre uma versão e outra antes mesmo de restaurar qualquer coisa.
O recurso permite drill down até o nível de elemento, ou seja, você não vê só "a versão 5 é diferente da versão 4", mas consegue identificar qual elemento específico foi alterado, adicionado ou removido. A partir de um save antigo no histórico, é possível criar uma nova versão do flow ou copiar a lógica daquele ponto específico para colar em outro flow.
O texto oficial não detalha limites de retenção do histórico nem requisitos de API version, então vale testar na sua org para entender até onde esse timeline retrocede.
Por que importa
Quem mantém flows complexos em produção sabe a dor de abrir uma versão antiga só para comparar visualmente elemento por elemento, tentando lembrar o que mudou e por quê. Isso é ainda pior quando o flow tem múltiplos colaboradores e ninguém documentou as alterações no changelog do próprio flow, algo que a maioria dos times simplesmente não faz na prática. Já perdi tarde inteira nesse exercício de arqueologia em projeto com flow de aprovação crítico, então esse recurso resolve uma dor que eu sentia na pele.
A possibilidade de copiar lógica de uma versão antiga para outro flow é o ponto que mais me chama atenção como arquiteto. Isso reduz a tentação de duplicar flows inteiros só para reaproveitar um trecho de lógica que funcionava bem numa versão anterior, um antipadrão que eu via com frequência em orgs com governança fraca sobre automação.
Como se preparar
- Verifique se os flows críticos da sua org já usam versionamento habilitado, já que o recurso só se aplica a flows que suportam essa funcionalidade.
- Treine a equipe de automação para consultar o Edit History antes de abrir um ticket de investigação sobre "por que esse flow mudou de comportamento", isso deve virar o primeiro passo de troubleshooting.
- Revise sua política interna de comentários e descrições em elementos de flow, porque o diff visual complementa mas não substitui uma boa documentação inline.
- Avalie usar o recurso de copiar lógica entre versões como parte do processo de refatoração de flows legados, especialmente antes de consolidar flows duplicados.
Nível de aplicação: Baixo
É um recurso nativo do Flow Builder que não exige configuração adicional, apenas uso consciente pela equipe de automação.
Considerações de arquiteto
- Mapear quais flows críticos da org já suportam versionamento antes de assumir que o Edit History estará disponível para todos eles.
- Incorporar a consulta ao Edit History como etapa obrigatória no processo de troubleshooting de automações, antes de escalar para investigação manual.
- Usar a função de copiar lógica entre versões como parte da estratégia de refatoração para reduzir duplicação de flows na sua org.
- Ajustar a política interna de descrições e comentários em elementos de flow, já que o diff visual mostra o que mudou mas não explica o porquê.
Pegadinhas:
- A Salesforce não detalha limites de retenção do histórico nem requisitos de API version, então a profundidade do timeline precisa ser validada empiricamente na sua org.
Este artigo faz parte do guia Flow na Winter '27, um item oficial por artigo. Fonte: release notes de Automation.