// Referência técnica

Salesforce Flow: referência prática

Flow é a ferramenta de automação declarativa do Salesforce e, desde a aposentadoria do Workflow Rules e do Process Builder, a única suportada para automação sem código na plataforma. Na Winter '27 ele ganha Test Mode, histórico por versão, tags e ações em massa — o conjunto que finalmente permite tratar automação como engenharia, com teste e rastreabilidade, e não como configuração solta.

55 artigos sobre o assuntoEsta página revisada em 22 de setembro de 2026 por Guilherme Dornelas
// O que costumam me perguntar

Quando usar Flow e quando partir para Apex?

Flow cobre a maior parte da automação de negócio: criar e atualizar registros, orquestrar aprovação, tela guiada, integração via HTTP Callout. Apex entra quando há lógica que o Flow não expressa sem virar gambiarra — recursão controlada, manipulação pesada de coleções, callouts com tratamento de erro sofisticado, ou volume que estoura os limites de elementos executados. O critério prático não é "dá para fazer em Flow", é "o próximo arquiteto vai entender isso em seis meses".

Quantos Flows por objeto?

Não há limite técnico de Flows por objeto, e desde a Spring '22 a ordem entre Record-Triggered Flows do mesmo objeto e contexto pode ser definida explicitamente pelo campo Trigger Order, de 1 a 2000. Dividir a automação em Flows menores e ordenados é opção legítima, não risco. Os que ficam sem Trigger Order definido rodam depois dos que têm, na ordem das datas de ativação das versões — previsível, mas frágil: reativar um Flow muda a posição dele. Sobre limites, o teto de 2.000 elementos executados deixou de existir na API 57.0; o que continua valendo por transação são os limites da plataforma (SOQL, DML, CPU), compartilhados por tudo que roda ali.

Fonte: Define the Run Order of Record-Triggered Flows (Salesforce Help)

Como testar um Flow antes de subir para produção?

Até a Winter '27, a resposta honesta era: rodando na sandbox e torcendo. O Test Mode muda isso ao permitir executar o Flow com dados controlados e verificar o resultado sem criar registro de verdade. Para automação crítica continua valendo cobrir o caminho com teste de Apex que dispara o Flow — o Test Mode é a rede, não o substituto.

Por que evitar DML e query dentro de loop no Flow?

Cada Get Records ou Update Records dentro de um loop consome um limite de governador por iteração. Com 200 registros, um update dentro do loop são 200 operações onde deveria haver uma. A forma correta é montar uma coleção dentro do loop e fazer uma única operação depois dele. É o erro mais comum em Flow feito por quem vem de ferramenta de automação de outro ecossistema.

// Tudo que escrevi sobre Flow
Acompanhar Flow

Recebe o que eu publicar sobre Flow junto da newsletter. Um email por edição, sem disparo a cada artigo.