Flow Test Mode: o teste declarativo que faltava

O gargalo que todo mundo fingia não ver

Flow sempre teve um ciclo de qualidade estranho: você constrói com rigor visual, mas testa no improviso. Debug manual, registro de teste criado na mão, ativa a versão e reza. Eu já perdi tempo de projeto assim, ativando fluxo em produção na confiança e corrigindo no susto quando algo quebrava. Em org grande, cada ativação era um pequeno ato de fé. A Winter '27 ataca isso com um pacote de cinco itens oficiais de testing, liderado pelo Flow Test Mode.

Flow Test Mode (beta): o centro do pacote

Um modo de teste dedicado no Flow Builder, substituindo o ciclo de debug improvisado por testes repetíveis: cenários salvos que rodam de novo a cada mudança, com resultado comparado ao esperado. Está em beta e marcado como preview nas notes: trate como complemento do seu processo, não como substituto ainda.

Os quatro companheiros oficiais

• Mock outputs para Action e Subflow (beta): dados de teste consistentes para callouts externos e respostas de subflow, sem depender de sistema vivo. Disponível em autolaunched e record-triggered: exatamente onde o risco mora.
• Debug por Record ID: cole o ID de 15/18 caracteres direto no debugger. Adeus caça ao registro em objetos de busca limitada como Case ou Campaign Member.
• Inputs de coleção no debugger: popular coleções de records e primitivas para testar cenários sem editar o flow. Antes, só valor único.
• Agentforce for Flow Headless gera cenários: o agente rascunha os cenários de teste a partir do terminal, sem abrir o Builder. O primeiro sinal concreto de IA no ciclo de qualidade declarativo.

Por que isso muda o jogo

O argumento que eu uso em projeto há anos: flow É software. Se muda comportamento de produção, merece teste que rode antes de cada mudança. Com Test Mode e mocks, a disciplina vira ferramenta: o cenário fica ao lado do flow, roda em segundos e quebra ANTES de a versão ruim ser ativada.

O efeito de segunda ordem me interessa mais: testável muda como você desenha. Quando testar é barato, você quebra flows gigantes em subflows testáveis, isola integrações atrás de mocks e nomeia melhor as variáveis. O Test Mode vai melhorar arquitetura até de quem nunca escrever um assertion.

Como se preparar

• No sandbox preview (29/08+), habilite em Process Automation Settings e comece pelos record-triggered de objetos core.
• Escreva o primeiro cenário para o caminho feliz e um para o fault path. Só isso já supera 99% das orgs.
• Teste os mocks num flow com callout: é onde o ganho aparece primeiro.

Fonte primária da série: release notes oficiais de Automation da Winter '27 (lidas na íntegra), com teste em preview org.

Nível de aplicação: Médio

Ainda em beta, exige mudança de processo de QA declarativo e não há garantia de todos os componentes migrarem intactos para GA.

Considerações de arquiteto

• Priorizar a cobertura de teste nos record-triggered flows de objetos core (Case, Opportunity, Lead) que já rodam em produção na org, começando pelos de maior impacto de negócio.
• Planejar o uso de mock outputs para isolar callouts externos antes de expandir Test Mode, evitando que testes fiquem dependentes de sistemas externos instáveis.
• Definir um padrão de nomenclatura e organização de cenários de teste desde já, já que a disciplina de testes vai influenciar diretamente o redesenho de flows monolíticos em subflows menores.
• Avaliar com a equipe de release management se a habilitação em Process Automation Settings no sandbox preview entra no ciclo normal de validação antes do rollout em produção.

Pegadinhas:

• Por estar em beta e marcado como preview, o Flow Test Mode não deve substituir o processo de QA existente nem ser tratado como gate de release oficial ainda.
• Mock outputs estão disponíveis apenas para flows autolaunched e record-triggered, então flows screen ou scheduled ficam de fora dessa cobertura por enquanto.