Análise editorial original do OrbTrail, ampliada com pesquisa complementar, contexto prático e referências verificadas.
As release notes de Winter ’27 introduzem a opção User Context—Enforces User Permissions para Screen Flows e Autolaunched Flows. Quando selecionada em How to Run the Flow, ela mantém a execução no nível de acesso do usuário mesmo se outro componente chamar a automação. A mudança responde a uma fonte persistente de risco: um Autolaunched Flow normalmente herda o contexto do chamador, de modo que a mesma lógica pode encontrar um conjunto diferente de objetos, campos e registros quando parte de uma tela, de outro Flow ou de uma ação automatizada.
A pergunta central não é se contexto de usuário é mais seguro em abstrato. É se a identidade que chega ao Flow representa realmente a pessoa cujo acesso deve limitar a operação. Em contexto de usuário, a documentação oficial diz que o Flow só alcança objetos, campos e registros acessíveis ao running user. Em contexto de sistema com compartilhamento, o compartilhamento de registros continua valendo, mas permissões de objeto e campo não; sem compartilhamento, as três camadas podem ser ignoradas. A nova opção torna uma escolha conservadora persistente, mas não muda quem é o usuário de execução.
OrbTrail interpreta o recurso como um contrato de autorização no limite do Flow. Ele é especialmente útil para automações reutilizadas, nas quais o criador não controla todos os chamadores futuros. Em vez de confiar que cada tela, subflow ou ação preserve um contexto seguro, o próprio Flow declara que não aceitará elevação herdada. Isso reduz surpresa arquitetural, mas transfere o trabalho para duas atividades mensuráveis: modelar o permission set mínimo de cada persona e provar que o chamador entrega a identidade esperada.
A identidade entra no limite
Tela, subflow ou agente fornece o running user. O nome do canal não prova quem essa identidade representa.
User Context fica fixo
A opção de Winter ’27 impede que o Flow herde uma execução mais ampla apenas por mudar o chamador.
CRUD, FLS e sharing são avaliados
Objeto, campo e registro precisam estar dentro do acesso efetivo da identidade de execução.
A ação permitida é executada
Get, Create, Update ou Delete só avança quando a persona possui a combinação necessária de permissões.
Negação vira resultado projetado
Fault paths e mensagens úteis devem explicar a falta de acesso sem revelar dados que o usuário não poderia consultar.
O que muda quando o Flow deixa de herdar o privilégio do chamador
Historicamente, o contexto padrão depende do tipo e da posição da automação. O guia do Salesforce Admins registra que um Screen Flow de nível superior roda em contexto de usuário por padrão, enquanto um Autolaunched Flow herda o contexto de quem o invoca, salvo configuração explícita. Isso significa que uma rotina aparentemente segura em teste manual pode se comportar de outra forma ao ser reutilizada por um chamador em contexto de sistema. A opção nova elimina essa variação para os dois tipos suportados: a política fica presa ao Flow e acompanha todas as rotas de invocação.
O recurso não converte Record-Triggered ou Schedule-Triggered Flows em automações de usuário; a release note limita a opção a Screen Flows e Autolaunched Flows. Também não concede acesso. O Trailhead separa a permissão para executar um Flow das permissões exigidas por seus elementos: um usuário pode conseguir iniciar a automação e ainda falhar ao criar um Case, editar um campo protegido ou ler um registro privado. Esse resultado é desejável quando revela um permission set incompleto; torna-se problema de experiência quando o Flow não oferece fault path e orientação acionável.
A implantação deve começar por um inventário de entradas e efeitos. Para cada Get, Create, Update, Delete e ação invocada, registre objeto, campos lidos ou alterados e condição de compartilhamento. Em seguida, execute o mesmo caso com uma persona mínima, uma persona operacional e uma persona administrativa. O critério de aceite não é apenas sucesso para o administrador: é sucesso para quem possui o acesso previsto, negação para quem não possui e nenhuma exposição de valor protegido na tela, mensagem de erro ou log destinado ao usuário.
Menos privilégio implícito exige um desenho explícito de falhas
Fixar contexto de usuário pode transformar acessos antes mascarados pelo modo de sistema em erros visíveis. Isso não é regressão automática; muitas vezes é a descoberta de que o processo dependia de elevação silenciosa. A decisão correta pode ser conceder uma permissão estreita, remover do Flow um campo desnecessário ou manter uma operação privilegiada em um serviço separado. Voltar todo o Flow para contexto de sistema apenas para eliminar o erro recupera funcionalidade ao custo de ampliar a superfície de dados.
Um exemplo prático é um Screen Flow de suporte que cria um Case e atualiza um campo de revisão. A equipe pode conceder Create no objeto Case e Edit somente nos campos necessários por um permission set dedicado. Se o campo de revisão é reservado à qualidade, o Flow do atendente não deveria gravá-lo escondido; uma automação posterior, com identidade e propósito próprios, pode assumir essa etapa. A fronteira entre as duas rotinas documenta por que existe elevação e reduz o número de elementos que operam acima do usuário.
Teste também o caminho negativo como produto. A mensagem deve dizer que a operação não pôde ser concluída e orientar o próximo passo, sem exibir nomes ou valores de campos inacessíveis. Registre Flow, versão, elemento, identidade e classe do erro em telemetria administrativa; não peça ao usuário para copiar uma pilha técnica. Depois compare falhas por permission set antes e depois da mudança. Um pico concentrado em uma persona indica contrato de acesso incompleto; uma falha somente diante de um registro privado aponta para compartilhamento, não para CRUD ou FLS.
Em Agentforce, contexto de usuário não significa contexto do cliente
A distinção fica crítica quando um Autolaunched Flow vira ação de agente. A documentação de segurança do Salesforce afirma que, em um agente voltado a funcionários, a ação usa a identidade de quem enviou o prompt; em um agente de serviço, usa a identidade do próprio agente. Portanto, selecionar User Context pode restringir corretamente um agente interno aos acessos do funcionário. Em atendimento externo, porém, restringe ao usuário técnico do agente — não transforma automaticamente o consumidor autenticado ou verificado no running user.
Para ações privadas de agentes de serviço, o guia oficial exige verificação da identidade do cliente e escopo dos dados por essa identidade. O exemplo usa VerifiedCustomerId como entrada controlada pelo contexto, valida o valor e limita cada registro retornado ou alterado àquele cliente. O novo modo de Flow deve ser tratado como uma camada complementar: ele contém o que a identidade do agente pode fazer na org; a lógica de verificação e vínculo contém o que aquele cliente específico pode pedir que o agente faça.
Antes de publicar uma ação, monte quatro casos: funcionário autorizado, funcionário sem acesso, cliente verificado associado ao registro e cliente verificado associado a outro registro. Acrescente entrada manipulada, ID inexistente e tentativa de alteração sensível sem confirmação. A ação só passa quando cada negação ocorre antes de retornar dados e quando uma confirmação explícita protege efeitos como envio de email ou mudança irreversível. A conclusão da OrbTrail é que Winter ’27 oferece um limite mais confiável para o Flow, mas segurança continua sendo a composição de identidade correta, menor privilégio, escopo do registro e tratamento previsível de falhas.
