Flow Builder: novo contexto de execução força permissões do usuário sempre

O que é

A Winter '27 adiciona uma nova opção de contexto de execução no Flow Builder chamada User Context, Enforces User Permissions. Ela garante que o flow sempre rode com o nível de acesso do usuário em execução, independentemente de quem ou o que dispare esse flow.

Essa opção está disponível para screen flows e autolaunched flows. O ponto central é a palavra "regardless": não importa se o flow foi chamado por um botão, por outro flow, por Apex ou por qualquer outro invocador, o comportamento de segurança passa a ser fixo e previsível.

Até então, o contexto de execução de um flow podia variar de acordo com o que o disparava, o que gerava inconsistência entre rodar com as permissões de quem clicou e rodar com privilégios elevados de sistema. Essa nova opção resolve exatamente essa ambiguidade, fixando o comportamento em "sempre respeitar o usuário".

Por que importa

Na prática, isso ataca um dos problemas mais recorrentes em auditorias de segurança de automação: flows que, dependendo do caminho de invocação, terminam rodando em modo de sistema sem que ninguém tenha decidido isso conscientemente. Já vi flow chamado diretamente por um usuário se comportar de um jeito, e o mesmo flow chamado por outro flow ou por um processo em background se comportar de outro, ignorando FLS e sharing rules sem aviso. Isso é o tipo de inconsistência que só aparece numa auditoria, quando já é tarde.

Com essa opção explícita, o arquiteto ganha uma forma declarativa de garantir que um flow sensível, por exemplo um que manipula dados restritos por sharing rules, nunca escape do contexto do usuário, mesmo se for reaproveitado como subflow em um contexto que normalmente rodaria elevado. Isso reduz a superfície de erro em automações complexas com múltiplos pontos de entrada, e facilita justificar em revisão de segurança que aquele flow específico não pode, por design, contornar permissões.

Como se preparar

• Mapeie os flows críticos da sua org que lidam com dados sensíveis e que hoje têm múltiplos pontos de invocação (botão, subflow, Apex, outro automation).
• Revise o contexto de execução atual desses flows e avalie se algum caminho de chamada está rodando em modo de sistema sem necessidade real.
• Para screen flows e autolaunched flows onde a regra de negócio exige que o usuário nunca veja ou altere mais do que tem permissão, ative a opção User Context, Enforces User Permissions.
• Inclua esse contexto de execução como item de checklist em revisões de segurança e em processos de code review de automação, principalmente para flows reutilizados como subflow.

Nível de aplicação: Médio

A ativação em si é um simples toggle no Flow Builder, mas o trabalho real está em mapear todos os pontos de invocação existentes e prever o impacto de FLS e sharing rules antes de mudar o contexto.

Considerações de arquiteto

• Antes de ativar essa opção em um flow reutilizado como subflow, valide se todos os flows pai dependem do comportamento elevado atual, pois a mudança pode quebrar fluxos que hoje contam com acesso de sistema.
• Faça o levantamento de campos e objetos manipulados pelo flow contra o perfil dos usuários finais, já que ativar o enforcement pode gerar erros silenciosos de FLS insuficiente em produção.
• Trate essa configuração como parte do processo de code review de automação, documentando explicitamente por que cada flow sensível ativa ou não o User Context, Enforces User Permissions.
• Priorize primeiro os flows que tocam dados restritos por sharing rules e que possuem múltiplos pontos de entrada, pois é ali que a inconsistência de contexto historicamente gera falhas de segurança.

Pegadinhas:

• A opção só está disponível para screen flows e autolaunched flows, então flows record-triggered ou baseados em outros tipos de trigger não recebem esse controle explícito.

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