Flow Builder: teste inputs de coleções primitivas e de registros no debugger

O que é

Até a Winter '27, o debugger do Flow Builder só aceitava valores únicos como input de teste. Se o seu flow começava com uma variável de coleção, seja ela uma coleção de registros ou uma coleção de tipos primitivos como texto, número ou booleano, você não conseguia popular esse input diretamente na tela de debug.

Com essa mudança, o debugger passa a permitir que você preencha coleções de registros e coleções primitivas diretamente na interface, sem precisar editar o flow antes de rodar o teste. Segundo o texto oficial, isso permite testar diferentes cenários sem alterar a definição do flow, o que reduz o tempo de desenvolvimento e melhora a cobertura de testes.

Na prática, isso vale para qualquer flow cujo ponto de entrada, seja um trigger de record-triggered flow, um screen flow ou um autolaunched flow, dependa de uma coleção como input. Antes, para simular esse cenário, era comum precisar de dados reais no ambiente ou de lógica auxiliar só para popular a coleção durante o teste. Eu mesmo já perdi tempo criando registros só para conseguir montar um teste decente de coleção, então essa mudança resolve uma dor bem real de quem vive o dia a dia do Flow Builder.

Por que importa

Essa é uma daquelas melhorias que não aparecem em keynote, mas que quem constrói flow complexo sente o peso todo dia. Testar lógica que itera sobre coleções, valida múltiplos registros ou processa listas de valores sempre foi um ponto de atrito no ciclo de desenvolvimento do Flow Builder. Muitas vezes eu via arquitetos e desenvolvedores criando registros de teste no sandbox só para conseguir montar uma coleção válida e rodar o debug, o que é lento e polui o ambiente com dados que depois precisam ser limpos.

Com o input de coleção direto no debugger, o ciclo de teste fica mais próximo do ideal: você isola a lógica do flow do estado do banco de dados. Isso é especialmente relevante para flows que tratam bulk, como record-triggered flows que processam vários registros de uma vez, onde bugs de lógica de coleção costumam aparecer só em produção porque o teste manual sempre usava um registro único.

Como se preparar

• Revise os flows que você mantém hoje e que recebem coleções de registros ou coleções primitivas como input de teste, especialmente os que tratam volume ou bulk.
• Aproveite para criar cenários de teste com coleções vazias, com um único item e com múltiplos itens, situações que antes exigiam manipulação de dados reais.
• Documente esses cenários de teste como parte da governança de qualidade do time, já que agora fica viável reproduzi-los rapidamente no debugger sem depender de dados de sandbox.
• Avalie se esse recurso reduz a necessidade de scripts ou dados fictícios que hoje existem só para viabilizar testes de flow.

Nível de aplicação: Baixo

É uma melhoria pontual na interface do debugger do Flow Builder, sem impacto em dados, integrações ou arquitetura de solução.

Considerações de arquiteto

• Priorize revisar primeiro os record-triggered flows que processam bulk, pois são onde bugs de lógica de coleção mais escapam para produção.
• Aproveite para formalizar cenários de teste padronizados (coleção vazia, um item, múltiplos itens) como parte da checklist de QA da sua org antes de qualquer deploy de flow.
• Avalie se esse recurso permite eliminar registros fictícios ou scripts de setup que hoje poluem o sandbox só para viabilizar debug de coleções.
• Comunique a mudança para o time de desenvolvimento, pois o hábito de testar com dado único no debugger está enraizado e pode mascarar bugs de bulk mesmo com o novo recurso disponível.

Pegadinhas:

• O suporte a coleções no debugger é um recurso novo do pacote de testing da Winter '27, então o debugger clássico da preview org ainda recusava esse tipo de input, o que pode gerar confusão se a ativação não estiver completa no seu release.

Este artigo faz parte do guia Flow na Winter '27, um item oficial por artigo. Fonte: release notes de Automation.