Winter ’27 no es una versión de IA. Es una versión de preparación.

Salesforce Winter ’27 llegó a las instancias que no son de vista previa el 9 y el 10 de octubre. Casi todo lo que se ha escrito sobre esta versión es una lista de funciones, y las funciones son buenas. Pero las actualizaciones de versión de Winter ’27 son la parte que cambia cómo se comporta tu org, las lea alguien o no, y tres de ellas deciden algo que las notas de la versión nunca mencionan: si un asistente de IA puede hacer trabajo útil en tu org.

Ninguna de las tres se describe como una función de IA. Ninguna va a aparecer en una demo. Justamente por eso vale la pena leerlas con atención.

Las actualizaciones de versión no son funciones, y la diferencia importa

Una función es algo que puedes elegir adoptar. Llega, queda disponible en Setup y, si nadie la activa, no pasa nada. La cobertura de una versión de Salesforce trata casi por completo de funciones, porque las funciones son aquello de lo que quiere hablar un proveedor y lo que quiere ver un lector.

Una actualización de versión es algo distinto. Es un cambio que Salesforce aplica a la plataforma con un calendario publicado, para mantenerla segura y sostenible, y que se impone en una fecha, lo haya revisado tu equipo o no. Puedes probar cada una por adelantado desde Actualizaciones de versión (Release Updates) en Setup. No puedes rechazarla.

Así que la lectura útil de cualquier versión no es “qué podríamos adoptar”. Es “qué va a ser cierto, hagamos algo o no”. En Winter ’27, esa segunda lista es corta, y tres de sus puntos describen, con bastante precisión, las condiciones que una org tiene que cumplir antes de poder dejar que un software actúe en su nombre.

Uno. Identidad: cada conexión necesita un nombre

A partir del 1 de diciembre de 2026, y en todas las orgs, cualquier usuario que no tenga el permiso Use Any API Auth ya no podrá autenticarse con la llamada login() de la API SOAP. Salesforce es explícita en que esto se aplica en todas partes, no solo en las instancias de vista previa, y la fecha no depende de cuándo reciba tu org Winter ’27.

La llamada de login de SOAP es antigua. También sigue viva en más lugares de los que la mayoría de los equipos imagina: conexiones de middleware, trabajos de extracción y carga, una herramienta de monitoreo que alguien configuró durante una implementación, un script escrito por un desarrollador que ya no está. Esas conexiones se ejecutan como un usuario. Ese usuario se creó para que la conexión funcionara, y casi siempre recibió lo que hiciera desaparecer el error.

Lo que hace el cambio es obligar a tomar una decisión explícita. Toda conexión no humana que use esa vía necesita ahora un permiso con nombre, asignado a propósito, a través de un perfil o un permission set. Convierte una categoría de acceso que se acumuló en silencio en una categoría de acceso que alguien tiene que aprobar.

Encontrarlas es menos trabajo del que parece. El Historial de inicio de sesión (Login History) en Setup se puede filtrar por tipo de inicio de sesión, lo que muestra qué usuarios se autentican por la API y no por el navegador, y las notificaciones de uso de la API te dirán cuáles de ellos tienen más actividad. La lista suele ser corta y suele sorprender: los equipos tienden a encontrar una o dos conexiones que ya no recordaban que seguían funcionando, lo cual es un hallazgo útil en sí mismo, con o sin la fecha de diciembre.

Es la misma disciplina que necesita un asistente de IA, y llega por una razón que no tiene nada que ver. La primera pregunta que trabajamos antes de que un cliente le dé acceso de escritura a un asistente es de quién hereda los permisos, y la respuesta honesta en la mayoría de las orgs es un encogimiento de hombros, porque la org ya contiene varias identidades que nadie considera usuarios. Escribimos ese proceso en las seis decisiones que tomamos antes de que una IA pueda escribir en una org de Salesforce, y la primera es la identidad precisamente por esto.

Un asistente no es el primer usuario no humano de tu org. Suele ser el quinto o el décimo. Solo es el primero que alguien mira de cerca.

Dos. Visibilidad: lo que la gente puede ver pasa a ser una decisión

El filtrado de perfiles (Profile Filtering) se impone en Winter ’27. Una vez activo, los usuarios dejan de ver los nombres de los perfiles distintos del suyo, salvo que tengan el permiso View All Profiles. El ajuste estuvo disponible por primera vez en Summer ’26, así que algunas orgs ya lo activaron por su cuenta; en Winter ’27, la opción desaparece.

Por sí solo, es una mejora de seguridad modesta. Los nombres de los perfiles revelan la estructura de la organización, y no hay una buena razón para que cada usuario pueda leer la lista completa. La salvedad práctica es acotada y vale la pena revisarla: si un flujo, un reporte o una pantalla personalizada les muestra nombres de perfiles a personas que no son administradoras, ese comportamiento cambió con la actualización de tu org.

La razón por la que entra en una conversación sobre preparación es lo que representa, más que lo que hace. En la mayoría de las orgs, la visibilidad se hereda. Es el resultado acumulado de decisiones tomadas durante una implementación, ajustadas por quien necesitaba algo una tarde cualquiera, y rara vez revisadas en conjunto. Con el filtrado de perfiles, Salesforce hace que una pieza de eso pase de heredada a decidida.

Esa distinción es toda la preparación para la IA en una frase. Un asistente que lee registros no crea un modelo de acceso nuevo; expone el que ya tienes, más rápido y de forma más legible de lo que podría una persona navegando formatos de página. Un campo que alguien no debería ver lleva años siendo técnicamente visible y prácticamente invisible, porque verlo habría implicado abrir un formato que nadie abre. Resumido en una frase, deja de ser prácticamente invisible. Ese es el argumento detrás de por qué la base, no el modelo, decide si la IA funciona, y es la razón por la que la pregunta que vale la pena hacer no es qué puede hacer el asistente, sino qué permite ya tu configuración.

Tres. Pruebas: automatización que puedes volver a ejecutar

La tercera está en beta, lo que normalmente la dejaría en una nota al pie. Esta no.

Winter ’27 incorpora un modo de prueba (Test Mode) dedicado en Flow Builder. Construir y probar ahora ocurren en el mismo lugar, un escenario de prueba se puede guardar y volver a ejecutar en lugar de cargarlo otra vez a mano, y un escenario puede llevar aserciones: condiciones que evalúan un resultado esperado, de modo que cada ejecución informa si pasa o falla en lugar de producir una salida que alguien tiene que revisar con lupa.

Los desarrolladores tienen esto desde hace años y no trabajarían sin ello. La automatización declarativa no lo tenía, y la consecuencia se nota en cualquier org con algo de antigüedad. Nadie quiere tocar el flujo que funciona desde 2022, porque la única forma de saber si un cambio rompió algo es hacer el cambio y esperar. Así que el flujo no se toca, acumula condiciones y, con el tiempo, sostiene algo importante y nadie lo entiende.

Es un problema que vale la pena resolver por sí mismo. Se vuelve urgente en el momento en que algo automatizado empieza a actuar sobre registros, porque ahora hay dos tipos de automatización sobre los mismos datos: los flujos que construyó tu equipo y lo que sea que se le permita hacer a un asistente. Qué pasa cuando los dos se disparan sobre el mismo registro no se responde leyendo ninguno de los dos. Se responde ejecutando una prueba.

Antes de que una org pueda dejar que un software actúe en su nombre, alguien tiene que poder decir qué hace la automatización existente, y cambiarla sin contener la respiración. Winter ’27 es la primera versión que trae la segunda mitad de eso.

Tres cosas que ya estaban en la lista de preparación

Identidades con nombre. Visibilidad decidida. Automatización que se puede verificar.

Esas tres actualizaciones de versión de Salesforce Winter ’27 no son un resumen de una versión de Salesforce. Son buena parte de lo que revisamos cuando un cliente pregunta si su org está lista para la IA, y esa ha sido la lista desde mucho antes de que existiera cualquiera de estos productos. Lo nuevo es que Salesforce ahora impone partes de ella como higiene de la plataforma, con fechas, por razones que no tienen nada que ver con la inteligencia artificial.

Eso resulta útil de una forma fácil de pasar por alto. El trabajo de preparación tiene fama de ser difícil de financiar, porque no produce ninguna demo y su beneficio es la ausencia de un problema futuro. Una actualización de versión produce una fecha límite. El trabajo es el mismo, y durante las próximas semanas tiene una fecha y una razón que no exige que nadie se ponga de acuerdo primero sobre la IA.

También significa que la conversación sobre preparación puede empezar sin un proyecto. Ninguna de las tres requiere una partida de presupuesto, un proveedor ni un piloto. Requieren que alguien abra Setup y lea tres listas.

Qué revisar ahora que tu org está en Winter ’27

Cinco cosas, en el orden en que las haríamos. Ninguna lleva más de una tarde.

Confirma que tu org ya se actualizó. Las instancias que no son de vista previa pasaron a Winter ’27 el 9 y el 10 de octubre. Si la tuya tiene otro calendario, Trust Status te da la fecha exacta en la pestaña de mantenimiento.

Lee las Actualizaciones de versión en Setup, para tu org. No un artículo general, incluido este. La lista de tu org muestra lo que se aplica a ti, en qué estado está cada punto y qué pruebas ofrece Salesforce para cada uno.

Encuentra cada conexión que use login() de SOAP. Después decide, una por una, si le asignas Use Any API Auth o si llevas la integración a un flujo de autenticación moderno. El 1 de diciembre está lo bastante lejos para hacerlo bien y lo bastante cerca para que, si se deja para el final, llegue durante las vacaciones de alguien.

Decide quién necesita View All Profiles. Con el filtrado de perfiles activo, quien no lo tenga ya no ve los demás perfiles. Ya que estás ahí, revisa si algo en tu org les muestra nombres de perfiles a personas que no son administradoras.

Elige tres flujos y escribe un escenario de prueba para cada uno. Elige los tres que el negocio notaría en menos de una hora si dejaran de funcionar. No los complicados: los que sostienen la operación. Es un ejercicio lo bastante pequeño para terminarlo de verdad, y es la forma en que un equipo descubre si vale la pena adoptar el modo de prueba en serio.

Lo que esta versión no toca

Vale la pena dejar claros los límites del argumento, porque una versión no puede arreglar lo que determina la mayor parte de los resultados de la IA.

Ninguna de estas tres actualizaciones de versión dice nada sobre si tus datos significan lo que la gente cree que significan. Acceso, visibilidad y automatización que se puede probar son preguntas sobre la maquinaria. No dicen nada sobre si dos equipos coinciden en qué es un lead calificado, si la etapa de una oportunidad refleja la conversación que realmente ocurrió, o si la cuenta que se cerró en marzo es la misma cuenta con tres nombres distintos.

Esa es la mitad más difícil de la preparación y no tiene fecha límite, y justamente por eso sigue quedando relegada frente al trabajo que sí la tiene. Un asistente que lee una org bien gobernada, pero llena de definiciones inconsistentes, va a responder con seguridad y equivocarse, y las respuestas seguras y equivocadas salen bastante más caras que una negativa a responder. Las actualizaciones de versión de Winter ’27 hacen que la maquinaria rinda cuentas. Las definiciones las tienes que resolver tú.

La parte que la versión no puede hacer por ti

Nada de esto deja lista a una org. Hace que las preguntas tengan respuesta, que es una afirmación más modesta y más útil.

La preparación no es una función que se instala. Es una propiedad de una org concreta: quién tiene acceso a qué, si ese acceso refleja cómo funciona el negocio hoy o cómo funcionaba en 2021, qué se ejecuta de forma automática, y si alguien puede decirlo con confianza. Lo interesante de Salesforce Winter ’27 es que una versión sin ninguna novedad de IA vuelve obligatorias, y con fecha, tres de esas preguntas.

La capa de conexión dejó de ser la parte difícil hace un tiempo, algo que escribimos cuando Salesforce MCP convirtió el acceso a una org en un problema resuelto. Lo que queda es la org en sí. Esta versión vuelve inevitable una parte de ese trabajo, y sería un desperdicio hacerlo como un trámite de cumplimiento sin notar que era el trabajo de preparación desde el principio.

Fuentes

Las tres actualizaciones de versión se leyeron directamente en las notas de la versión Winter ’27 de Salesforce el 24 de septiembre de 2026. Las fechas se tomaron de las páginas de Salesforce y no de fuentes secundarias. Todas las fuentes están en inglés.

• Assign Use Any API Auth Permission for SOAP login() (Release Update), notas de la versión Winter ’27 de Salesforce
• Enable Profile Filtering (Release Update), notas de la versión Winter ’27 de Salesforce
• Test Flows in a Dedicated Test Mode (Beta), notas de la versión Winter ’27 de Salesforce
• Salesforce Sandbox Preview Instructions, para las fechas del 9 y el 10 de octubre en las instancias que no son de vista previa

Las fechas de actualización de Winter ’27 varían según la instancia. Confirma la tuya en Salesforce Trust Status antes de planificar con cualquier fecha de este artículo.