Flow ou Apex: quando usar cada um no Salesforce

É a pergunta que todo time de Salesforce enfrenta ao automatizar um processo. A resposta errada custa caro: Flow demais vira uma teia impossível de manter, Apex demais engessa o que o admin poderia ajustar sozinho. Este guia dá a regra prática que eu uso na hora de decidir.

A regra de bolso

Comece pelo Flow. Vá para o Apex quando o Flow não dá conta com clareza, performance ou segurança. Automação declarativa é mais barata de manter e qualquer admin ajusta sem deploy. Código só entra quando ele resolve algo que o clique-e-configura não resolve bem.

Quando o Flow é a escolha certa

• Regras de negócio que o time de operação vai querer ajustar sem depender de dev.
• Atualização de campos, criação de registros relacionados, envio de e-mail ou notificação.
• Orquestração de aprovações e etapas com telas para o usuário.
• Integrações simples via ações invocáveis já prontas.

Quando vale a pena ir para o Apex

• Volume alto e bulkificação real: lógica que precisa rodar bem com 200 registros por transação sem estourar limites. Flow em cenário de massa complexo fica frágil.
• Lógica complexa ou recursiva: muitos ramos, cálculos encadeados, controle fino de recursão. Em Flow isso vira um labirinto visual.
• Callouts e integrações não triviais: chamadas HTTP com tratamento de erro, retry, ordenação callout-antes-de-DML.
• Performance sensível: quando cada milissegundo e cada limite de governador contam.
• Testabilidade: Apex tem testes automatizados de verdade, com asserts e cobertura. Em lógica crítica, isso é diferencial de qualidade.

A zona cinzenta: os dois juntos

O melhor dos mundos costuma ser híbrido. O admin monta o Flow, e o Flow chama uma ação invocável em Apex (@InvocableMethod) para a parte pesada. Assim a operação mantém o controle declarativo e o dev encapsula a complexidade num bloco testado e reutilizável.

Essa mesma tensão entre declarar regras e escrever lógica reaparece na criação de agentes de IA. Vale ver como o Agentforce Builder novo e o Agent Script tratam a decisão do que é regra fixa e o que é conversa com o modelo.

public class CalcularComissao {
    @InvocableMethod(label='Calcular comissão')
    public static List<Resultado> run(List<Pedido> pedidos) {
        // lógica bulkificada e testada, chamada de dentro do Flow
    }
}

Os erros mais comuns (independente da escolha)

• DML ou consulta dentro de loop: tanto em Flow quanto em Apex, é o caminho mais rápido para estourar limites de governador em produção. Se você já viu o Too many SOQL queries: 101, vale entender por que o Apex quebra só com volume e como bulkificar para o erro não voltar.
• Vários Flows disparando no mesmo objeto: ordem imprevisível e difícil de depurar. Prefira consolidar.
• Apex sem teste ou com teste que só busca cobertura: teste tem que afirmar comportamento, não só passar a linha.
• Escolher pela preferência pessoal, não pelo caso: "só faço Flow" ou "só faço Apex" é sinal de alerta. A ferramenta certa depende do problema.

Sobre o Flow ser difícil de depurar em produção: isso mudou. Se você escolheu Flow e precisa entender por que ele falha, veja como o Flow Logging grava cada execução no Data Cloud e aponta o elemento culpado sem você ter que reproduzir o erro no escuro.