Testes de Flow com mock outputs em Action e Subflow (Beta)

O que é

Mock outputs é um recurso beta que permite definir dados de teste consistentes para elementos Action e Subflow dentro de flows autolaunched e record-triggered. Em vez de o teste depender de um callout externo real ou da execução completa de um subflow, você define uma saída simulada que o Flow usa durante o teste.

Segundo as release notes, o objetivo é testar esses flows "de forma mais confiável", sem depender de sistemas ao vivo ou serviços externos. Isso vale tanto para chamadas de Action, como invocações de Apex, integrações externas ou ações declarativas, quanto para respostas vindas de subflows.

O recurso está disponível para autolaunched flows e record-triggered flows. Como é beta, ainda não tem garantia de disponibilidade geral nem SLA de suporte formal, e o comportamento pode mudar até a liberação definitiva.

Por que importa

Quem já tentou montar uma suíte de testes decente para flows sabe o problema, qualquer callout externo instável, lento ou fora do ar quebra o teste, mesmo que a lógica do flow esteja correta. O mesmo vale para subflows que dependem de dados de contexto difíceis de reproduzir. Isso empurra times para testar menos, ou para testar só manualmente, o que é ruim em qualquer processo de CI/CD sério. Já vi projeto perder um dia inteiro de sprint só porque o callout de teste caiu no meio da validação, sem nenhum problema real na lógica do flow.

Com mock outputs, dá para isolar a lógica de orquestração do flow da confiabilidade do sistema externo. Isso aproxima o Flow Builder de práticas normais em desenvolvimento de software, tipo unit test com dependências mockadas, e reduz falso negativo em pipeline de deploy. Para arquiteturas que dependem de Named Credentials, integrações REST ou subflows reutilizáveis, esse tipo de teste passa a ser viável em escala, não só em ambiente sandbox com sorte de tudo estar no ar.

Como se preparar

• Mapeie hoje quais dos seus flows autolaunched e record-triggered têm elementos Action ou Subflow que dependem de callouts externos ou de outros flows, esses são os candidatos naturais para mock outputs.
• Como é beta, valide na sandbox antes de assumir que vai virar prática padrão em produção, e acompanhe as release notes para mudanças de comportamento.
• Revise sua estratégia de testes de Flow existente, se você já usa Flow Test ou testes manuais, planeje onde os mock outputs entram no fluxo de trabalho.
• Documente quais saídas mockadas representam cenários reais de erro e sucesso do sistema externo, não só o caminho feliz.

Nível de aplicação: Baixo

É um recurso de teste opt-in no Flow Builder, sem impacto em runtime de produção nem em dados, ideal para experimentar na sandbox antes de padronizar.

Considerações de arquiteto

• Faça o levantamento na sua org de quais flows autolaunched e record-triggered concentram Actions de callout externo ou Subflows críticos, priorizando esses para o piloto de mock outputs.
• Trate isso como extensão da estratégia de Flow Test já existente, definindo quem na equipe é responsável por manter os cenários mockados atualizados quando a integração externa mudar de contrato.
• Como é beta, não coloque mock outputs como dependência de gate de deploy em produção ainda, mantenha como camada complementar de validação na sandbox.
• Documente cenários de falha do sistema externo (timeout, erro 4xx, payload inesperado) além do caminho feliz, já que é justamente isso que a suíte de testes manual da sua org costuma negligenciar.

Pegadinhas:

• Por ser beta, a Salesforce não garante disponibilidade geral nem SLA de suporte, então o comportamento do recurso pode mudar antes do GA.

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