Flow Builder agora valida o tamanho de campo ao salvar

O que é

Esse guardrail valida restrições de tamanho de campo no momento em que você desenha e salva um flow. Se um elemento Assignment tenta atribuir a um campo de registro um valor de texto que ultrapassa o limite definido para aquele campo, o Flow Builder mostra um warning no momento do save.

O diferencial aqui é a precisão do aviso. O texto oficial deixa claro que a validação identifica o campo específico e o valor que excede o limite, não é um alerta genérico de "há um problema neste elemento". Isso muda a forma como você debuga, em vez de rodar o flow, esperar ele falhar em runtime e só então caçar qual Assignment causou o erro, você recebe o apontamento direto na hora de salvar.

É importante entender o escopo, a validação cobre Assignment elements atribuindo valores de texto a campos de registro. Não é uma checagem geral de todos os tipos de dado ou de todos os elementos do flow, é especificamente esse cenário de estouro de tamanho em campo texto via Assignment.

Por que importa

Na minha experiência de projeto, erro de tamanho de campo é um dos tipos de falha mais bobos e mais recorrentes em flow. Alguém concatena strings num Assignment, ou monta um valor dinâmico a partir de múltiplos campos, e esquece que o campo de destino tem limite de 80 ou 255 caracteres. O flow passa no teste com dados de exemplo curtos e quebra semanas depois quando um usuário digita um valor mais longo, e eu já perdi tempo demais caçando esse tipo de erro em log de produção.

Esse guardrail desloca a detecção do erro para a esquerda, do runtime para o momento de design. Isso é exatamente a filosofia que a Salesforce vem seguindo com outros guardrails de save recentes: reduzir a superfície de erros que só aparecem depois que o flow já está em produção e já afetou um usuário real. Como arquiteto, isso significa menos tempo gasto revisando logs de erro de flow e mais confiança de que o que passou no save é estruturalmente sólido, pelo menos nesse aspecto específico.

Como se preparar

• Revise flows existentes que fazem Assignment de valores concatenados ou formatados para campos de texto, são os candidatos mais prováveis a disparar o warning quando você reabrir e salvar o flow.
• Não trate o warning como bloqueio automático, ele é um alerta para você avaliar se o cenário de dado longo é realista no seu processo de negócio.
• Aproveite para revisar o tamanho dos campos de destino versus o volume real de dados que o flow pode gerar, às vezes o problema não é o flow, é o campo que está subdimensionado.
• Inclua esse tipo de checagem no seu processo de code review de flows, mesmo com o guardrail automático, vale documentar por que um Assignment específico lida com valores longos.

Nível de aplicação: Baixo

É um warning automático no save do Flow Builder, sem necessidade de configuração ou código adicional na sua org.

Considerações de arquiteto

• Priorize revisar flows que fazem concatenação de strings ou montagem dinâmica de valores antes de reabrir e salvar em produção, para não ser pego de surpresa por warnings acumulados.
• O escopo é limitado a Assignment elements atribuindo texto a campos de registro, então não conte com essa validação para pegar estouros em outros elementos como Create Records ou Update Records com fórmulas complexas.
• Use o momento de aparecimento do warning para reavaliar o dimensionamento do campo de destino na sua org, às vezes a correção correta é aumentar o tamanho do campo e não mudar o flow.
• Documente no processo de code review por que determinados Assignments lidam com valores potencialmente longos, mesmo que o warning não bloqueie o save, isso evita retrabalho de investigação futura.

Pegadinhas:

• O warning não bloqueia o save, então times menos disciplinados podem simplesmente ignorá-lo e deixar o risco de erro em runtime intacto.

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