Análisis editorial original de OrbTrail ampliado con investigación complementaria, contexto práctico y referencias verificadas.
Las release notes de Winter ’27 incorporan User Context—Enforces User Permissions para Screen Flows y Autolaunched Flows. Al seleccionarlo en How to Run the Flow, la ejecución permanece en el nivel de acceso del usuario aunque otro componente invoque la automatización. El cambio aborda un riesgo persistente: un Autolaunched Flow normalmente hereda el contexto de su invocador, por lo que la misma lógica puede encontrar objetos, campos y registros distintos si parte de una pantalla, otro Flow o una acción automatizada.
La pregunta central no es si el contexto de usuario es más seguro en abstracto. Es si la identidad que llega al Flow representa a la persona cuyo acceso debe limitar la operación. En contexto de usuario, la guía oficial dice que el Flow solo alcanza objetos, campos y registros disponibles para el running user. El contexto de sistema con sharing mantiene el acceso a registros, pero no permisos de objeto o campo; sin sharing, pueden omitirse las tres capas. La opción nueva hace persistente una elección conservadora, pero no cambia quién es el usuario de ejecución.
OrbTrail interpreta la función como un contrato de autorización en el límite del Flow. Resulta especialmente útil para automatizaciones reutilizables cuyo autor no controla todos los invocadores futuros. En vez de confiar en que cada pantalla, subflow o acción conserve un contexto seguro, el propio Flow declara que no aceptará elevación heredada. Eso reduce sorpresas arquitectónicas, pero traslada el trabajo a dos actividades medibles: diseñar el permission set mínimo de cada persona y demostrar que cada invocador entrega la identidad esperada.
La identidad cruza el límite
Pantalla, subflow o agente entrega el running user. El nombre del canal no demuestra a quién representa esa identidad.
El contexto de usuario queda fijo
La opción de Winter ’27 impide que el Flow herede una ejecución más amplia solo porque cambie su invocador.
Se evalúan CRUD, FLS y sharing
Objeto, campo y registro deben estar dentro del acceso efectivo de la identidad de ejecución.
Se ejecuta la acción permitida
Get, Create, Update o Delete solo avanza cuando la persona posee la combinación necesaria de permisos.
El fallo se convierte en resultado diseñado
Fault paths y mensajes útiles deben explicar la falta de acceso sin revelar datos que el usuario no podría consultar.
Qué cambia cuando un Flow deja de heredar el privilegio de su invocador
Históricamente, el contexto predeterminado depende del tipo y la posición de la automatización. La guía de Salesforce Admins indica que un Screen Flow de nivel superior se ejecuta en contexto de usuario, mientras que un Autolaunched Flow hereda el contexto de quien lo invoca salvo configuración explícita. Una rutina que parece segura en una prueba manual puede comportarse de otra forma cuando la reutiliza un invocador en contexto de sistema. La opción nueva elimina esa variación para los dos tipos admitidos: la política pertenece al Flow y acompaña todas sus rutas de invocación.
La función no convierte Record-Triggered o Schedule-Triggered Flows en automatizaciones de usuario; la release note la limita a Screen Flows y Autolaunched Flows. Tampoco concede acceso. Trailhead distingue el permiso para ejecutar un Flow de los permisos que requieren sus elementos: una persona puede iniciar la automatización y fallar al crear un Case, editar un campo protegido o consultar un registro privado. Esa denegación es útil si revela un permission set incompleto, y se vuelve mala experiencia si el Flow no ofrece fault path ni una orientación práctica.
La implantación debe comenzar con un inventario de entradas y efectos. Para cada Get, Create, Update, Delete y acción invocada, registra objeto, campos leídos o modificados y condición de sharing. Después ejecuta el mismo caso con una persona de acceso mínimo, una persona operativa y una administradora. El criterio de aceptación no es solo el éxito del administrador: es éxito para quien tiene acceso previsto, denegación para quien no lo tiene y ninguna fuga de valores protegidos en pantalla, error visible o log destinado al usuario.
Menos privilegio implícito exige diseñar el fallo de forma explícita
Fijar el contexto de usuario puede convertir accesos antes ocultos por el modo de sistema en errores visibles. Eso no es una regresión automática; a menudo revela que el proceso dependía de una elevación silenciosa. La respuesta correcta puede ser conceder un permiso estrecho, retirar del Flow un campo innecesario o aislar una operación privilegiada en un servicio separado. Devolver todo el Flow al contexto de sistema solo para eliminar el error recupera funcionalidad ampliando la superficie de datos.
Pensemos en un Screen Flow de soporte que crea un Case y actualiza un campo de revisión. El equipo puede conceder Create sobre Case y Edit solo en los campos necesarios mediante un permission set dedicado. Si el campo de revisión corresponde a calidad, el Flow del agente no debería escribirlo de forma invisible; una automatización posterior, con identidad y propósito propios, puede asumir esa etapa. El límite entre ambas rutinas documenta por qué existe la elevación y reduce los elementos que operan por encima del usuario.
Prueba también la denegación como parte del producto. El mensaje debe indicar que la operación no pudo completarse y ofrecer un siguiente paso sin mostrar nombres ni valores de campos inaccesibles. La telemetría administrativa debe registrar Flow, versión, elemento, identidad y clase de error; no pidas al usuario copiar una traza técnica. Compara fallos por permission set antes y después. Un aumento concentrado en una persona sugiere un contrato de acceso incompleto; un fallo solo ante un registro privado apunta a sharing y no a CRUD o FLS.
En Agentforce, contexto de usuario no significa contexto del cliente
La diferencia se vuelve crítica cuando un Autolaunched Flow es una acción de agente. La documentación de seguridad de Salesforce afirma que un agente orientado a empleados ejecuta la acción con la identidad de quien envió el prompt, mientras que un agente de servicio usa la identidad del propio agente. Seleccionar User Context puede limitar correctamente un agente interno al acceso del empleado. En atención externa, en cambio, limita al usuario técnico del agente; no convierte automáticamente al consumidor autenticado o verificado en running user.
Para acciones privadas de agentes de servicio, la guía oficial exige verificar la identidad del cliente y acotar los datos a esa identidad. Su ejemplo pasa VerifiedCustomerId desde contexto controlado, valida el valor y limita cada registro devuelto o alterado a ese cliente. El nuevo modo de Flow es complementario: contiene lo que la identidad del agente puede hacer en la org, mientras que la verificación y la relación contienen lo que ese cliente específico puede pedir al agente.
Antes de publicar una acción, crea cuatro casos: empleado autorizado, empleado sin acceso, cliente verificado relacionado con el registro y cliente verificado relacionado con otro registro. Añade una entrada manipulada, un ID inexistente y una mutación sensible sin confirmación. La acción solo pasa si cada denegación ocurre antes de devolver datos y una confirmación explícita protege efectos como enviar correo o realizar un cambio irreversible. OrbTrail concluye que Winter ’27 ofrece un límite más confiable para Flow, pero la seguridad sigue siendo la composición de identidad correcta, mínimo privilegio, alcance del registro y tratamiento previsible de errores.
