Gerar Thread IDs em loops no Flow destrói os limites DML do Email-to-Case

O problema real: DML escondido dentro de um loop

Uma discussão recente no Salesforce Stack Exchange trouxe à tona um cenário clássico de Service Cloud que silenciosamente destrói automações em produção. O desafio era inserir o Thread ID do Email-to-Case no corpo de um e-mail disparado por Flow, mantendo o token invisível para o cliente final e sem quebrar os limites de governança da org.

O caso real envolvia o envio de e-mails para múltiplos contatos a partir de um mesmo Caso. Para garantir que as respostas voltassem ao registro correto sem abrir chamados duplicados, foi criada uma ação invocável em Apex usando o método EmailMessages.getFormattedThreadingToken(). O plano inicial era colocar essa ação dentro de um loop no Flow para gerar e capturar o token de cada destinatário individualmente.

Se você já construiu automações complexas no Salesforce, sabe que Apex invocável dentro de Loop de Flow é receita para desastre. Sempre foi, e continua sendo.

O contexto técnico que ninguém lê na documentação

O Email-to-Case depende de uma referência forte para vincular a resposta do cliente ao Caso original. Durante anos, a solução padrão era o famoso Ref ID, aquela string visível no assunto ou no rodapé da mensagem. Com as atualizações de segurança mais recentes da Salesforce, a plataforma passou a priorizar o rastreamento via cabeçalhos de e-mail (Email Headers) combinado a tokens específicos. O método getFormattedThreadingToken() existe exatamente para recuperar esse token em formato de string utilizável em templates e automações.

Até aqui, tudo parece razoável. O problema está em um detalhe que a documentação oficial menciona de forma discreta e que a maioria dos implementadores ignora até levar o erro em produção:

A pegadinha do DML implícito

Se o token de threading ainda não existir para aquele Caso específico no momento da chamada, o método getFormattedThreadingToken() força uma operação DML nos bastidores para gerá-lo e persistir no banco de dados. Essa geração não é uma leitura — é uma escrita.

Coloque essa ação invocável dentro de um loop processando dezenas de contatos e o resultado é previsível:

• Uma chamada DML por iteração do loop
• Estouro dos limites de governança da org em fluxos com volume moderado
• Falha completa do Flow, sem rollback parcial, sem registro salvo

O Flow não avisa. Ele simplesmente falha. E o log de erro aponta para limite DML excedido, sem deixar óbvio que a origem é um método aparentemente "só de leitura" chamado em loop.

A solução arquitetural: processar uma vez, armazenar, reutilizar

A correção não está em tentar otimizar o loop nem em reorganizar a ordem das ações dentro do Flow. Está em mudar a arquitetura da solução com base em um princípio simples:

Gere o dado caro uma única vez, no momento certo, de forma assíncrona. Quando a automação precisar dele, ele já deve existir.

Na prática, a abordagem recomendada funciona assim:

1. Na criação do Caso, dispare um processo assíncrono — preferencialmente Queueable Apex, que chama getFormattedThreadingToken() e salva o resultado em um campo de texto personalizado no próprio objeto Case.
2. No Flow de envio de e-mails, elimine completamente a ação Apex invocável. O Flow simplesmente referencia o campo personalizado como variável de merge, seja no texto do template ou em qualquer campo de texto dinâmico.

O resultado prático:

• Zero chamadas DML durante o envio dos e-mails
• Sem risco de estouro de limites independente do volume de destinatários
• Flow mais simples, mais rápido e mais fácil de manter
• Token disponível para qualquer outra automação que precise dele no futuro

Sobre o texto invisível no corpo do e-mail

A discussão original mencionou a tática de embutir o token no corpo do e-mail usando texto com cor branca ou letras minúsculas, um truque herdado da era dos Classic Email Templates para esconder o Ref ID do cliente final.

Antes de adotar essa abordagem, considere os riscos reais:

• Clientes de e-mail modernos, especialmente no modo noturno ,invertem esquemas de cor. Texto branco sobre fundo branco vira texto preto sobre fundo escuro. O token aparece.
• Algumas plataformas de e-mail reformatam o HTML antes da entrega, quebrando completamente o efeito de ocultação.
• A recomendação primária da Salesforce é confiar no rastreamento por cabeçalho nativo, que não toca no corpo da mensagem e não expõe string alguma ao cliente.

Se a exigência de negócio for inegociável e o token precisar estar no corpo, a abordagem do campo personalizado resolve o problema técnico de geração. Mas a decisão de inserir o token no corpo versus confiar nos cabeçalhos é uma conversa de requisito que precisa acontecer antes da implementação — não depois do primeiro bug relatado pelo cliente.

A lição arquitetural que fica

Esse cenário ilustra um padrão de erro muito comum em implementações Salesforce: forçar a plataforma a executar operações custosas no exato momento do disparo de uma automação voltada para o usuário final.

Soluções escaláveis funcionam ao contrário. Elas preparam o dado com antecedência — de forma assíncrona e desacoplada — para que a automação de interface seja o mais leve, segura e resiliente possível. Quando o Flow roda, ele apenas lê. Quem escreveu foi outro processo, em outro momento, dentro dos limites corretos.

Simples assim. E é exatamente essa simplicidade que diferencia uma arquitetura que aguenta crescimento de uma que quebra na primeira campanha com volume fora do padrão.