Winter '27 ya está en tu org: cómo decidir qué activar antes de que llegue la próxima release
Actualizado: 10 oct
Para gerentes de TI y dueños de Salesforce que ven pasar tres releases al año sin tiempo para revisarlas. Al terminar vas a tener un orden de cuatro pasos para elegir, probar y lanzar las novedades que mueven tu operación.
Una release de Salesforce vale lo que tu equipo alcance a activar. Lo demás se queda en tu org sin uso hasta que llega la siguiente, que trae su propia lista.
Winter '27 empezó a llegar a las orgs de producción en septiembre, por oleadas, con los últimos fines de semana de despliegue a comienzos de octubre (Salesforce Ben, Salesforce Winter '27 Is Live: 12 Features to Share With Your Team, 2026).
Trae resúmenes automáticos después de cada llamada, notas de voz desde la app móvil, un pronóstico con señales de riesgo y una de las actualizaciones más grandes de Flow Builder en años. Buena parte de esas funciones llega apagada, así que alguien en tu empresa tiene que decidir cuáles encender, para quién y en qué orden.
En las orgs que revisamos, ese alguien pocas veces tiene nombre. El administrador está cerrando tickets, TI tiene otros proyectos en curso y la nota de la release queda sin abrir en el correo de alguien.
Mientras tanto, tu equipo comercial sigue armando el pronóstico en Excel aunque Salesforce ya lo resuelve.
Vas a encontrar qué cambió con Winter '27 para ventas, servicio y administración, por qué tantas novedades se quedan sin uso y cómo activarlas sin desordenar la operación.
Winter '27 enciende algunos cambios y deja otros esperando
Para ventas, la release suma un resumen con decisiones y próximos pasos que se genera sobre Einstein Conversation Insights cuando termina la llamada. El vendedor también puede grabar una nota de voz desde la app móvil apenas corta, mientras todavía recuerda el contexto.
El pronóstico, por su parte, junta en una sola vista el riesgo de cada negocio, las señales por contacto y un mapa de calor de la actividad.
Para servicio, los casos conservan los adjuntos originales y traen herramientas para ajustar el tono de una respuesta o resumirla. Cuando una conversación se redirige a otro canal o a otro agente, el cliente recibe un mensaje que le explica qué está pasando.
Para administración, el cambio fuerte está en Flow Builder. Test Mode, todavía en beta, guarda escenarios de prueba que puedes repetir después de cada ajuste.
Los screen flows que se lanzan desde una vista de lista ahora reciben todos los registros seleccionados, así que una actualización masiva ya no necesita código. El historial de cambios del objeto Usuario quedó disponible de forma general, con hasta 20 campos rastreables (Salesforce Ben, 2026).
Varias de estas mejoras vienen desactivadas por defecto. Otras, en cambio, se aplican solas.
Con Winter '27, Salesforce volvió obligatorio el filtro de perfiles: cada usuario ve solo el nombre de su propio perfil, salvo que tenga el permiso View All Profiles. Si algún proceso tuyo dependía de ver perfiles ajenos, ya cambió aunque nadie en tu empresa lo haya decidido.
Cada release te deja dos tareas: decidir qué encender y revisar qué se encendió solo.
Como Salesforce publica tres releases al año, ese trabajo vuelve cada cuatro meses.
¿Quién lee la nota de release en tu empresa?
Cuando hacemos esa pregunta en un diagnóstico, la respuesta suele tardar. A veces aparece el nombre del administrador, que abre la nota cuando un usuario reclama porque algo dejó de funcionar.
Entonces el equipo investiga hacia atrás, con la operación detenida, un cambio que podía haber revisado con semanas de anticipación.
El segundo síntoma es más silencioso: las novedades útiles no llegan a quien las necesita. Tu gerente comercial no sabe que el pronóstico ahora muestra el riesgo de cada negocio, así que sigue pidiendo el reporte del lunes en Excel.
Tu jefe de servicio tampoco sabe que el agente puede ajustar el tono de una respuesta, por eso sus ejecutivos copian el texto a otra herramienta para corregirlo. Salesforce ya entregó la mejora, aunque tu equipo sigue trabajando como antes.
El tercero es el más caro, porque viene de decisiones de hace años. Si tu equipo resolvió la actualización masiva con código a medida, la mejora de los flows sobre varios registros no te sirve hasta que alguien rehaga ese proceso.
Si tu operación de servicio corre sobre objetos personalizados, las mejoras de los casos llegan a un objeto estándar que nadie usa.
Cada personalización que esquiva el estándar también esquiva las tres releases del año.
Por eso la brecha entre lo que Salesforce ofrece y lo que tu org recibe crece con cada release.
El último aparece cuando alguien sí se anima a activar algo. Lo hace directo en producción, para todos los usuarios y sin aviso previo.
El equipo recibe la novedad como un cambio impuesto, encuentra un detalle que no calza con su proceso y vuelve a lo de antes. La siguiente vez, nadie quiere tocar nada.
De la nota de release al sandbox en cuatro pasos
El orden que usamos es el mismo que compartió nuestra cofundadora Cristina Fritz para Winter '27.
Antes de partir, conviene un paso previo: revisar lo que la release cambió por su cuenta, como el filtro de perfiles, para descartar que algo ya se haya roto sin que nadie lo note.
Primero, elige dos o tres novedades con impacto real en tu operación. Sirven las que resuelven algo que hoy tu equipo hace a mano o fuera de Salesforce. Si tus vendedores registran la visita horas después de salir del cliente, las notas de voz valen más que cualquier otra novedad de la lista.
Activar diez funciones a la vez garantiza que ninguna se use bien.
Segundo, revisa perfiles y permisos de quienes las van a usar. Varias novedades dependen de un permiso, de una licencia o de una configuración previa.
Winter '27 además suma un modo de ejecución para flows que respeta los permisos de la persona que los corre. Conviene que tu equipo acuerde cuándo usarlo por defecto, antes de que cada administrador decida por su lado.
Tercero, pruébalas en sandbox con un usuario por área. Con Test Mode de Flow Builder, además, puedes guardar el escenario de prueba y repetirlo en la próxima release sin armarlo de nuevo.
El administrador sabe si la función se configura bien, pero solo el vendedor sabe si le ahorra tiempo en una visita real.
Cuarto, comunícalas con un ejemplo del propio proceso. Una captura del pronóstico con negocios reales de tu cartera convence más que la nota oficial de Salesforce traducida al español.
Este trabajo pide continuidad, porque se repite tres veces al año. Nuestro Soporte Especializado opera la org de forma continua y mide su salud con un índice que combina deuda técnica, seguridad, adopción y estabilidad, revisado cada trimestre.
Una release bien activada empuja la adopción, mientras que cada personalización que deja de bloquear el estándar baja la deuda.
Cuando la org tiene tanta lógica a medida que las novedades no tienen por dónde entrar, el punto de partida es un Quick Audit: dos semanas para saber qué parte de esa personalización puede volver al estándar.
Dos orgs donde la release no tenía por dónde entrar
Una administradora de fondos de pensiones había dejado de usar Service Cloud en sus canales asistidos a los pocos meses de lanzarlo, por lentitud y cortes en la integración con la telefonía.
Al auditar la org encontramos cientos de clases de código a medida, con la lógica del negocio repartida en capas sin una orquestación central. Cada release mejoraba un Service Cloud estándar que esa org casi no tocaba.
Clasificamos el código en cuatro cuadrantes para priorizar qué alinear con las capacidades nativas. Con esa clasificación armamos un roadmap para concentrar la atención en Service Cloud y dar de baja el sistema paralelo donde los ejecutivos registraban todo por segunda vez.
El diagnóstico y el roadmap ya están entregados, junto con un rediseño de licencias que bajó el costo de la integración. Lo que viene es que, a medida que la lógica vuelva al estándar, cada release llegue a la operación sin rehacer código.
Una distribuidora de repuestos tenía pagadas las licencias de una nube de industria para su fuerza de venta en terreno. Sin embargo, la operación corría sobre objetos personalizados que había construido un proveedor anterior, en vez del modelo estándar de esa nube.
Las mejoras que Salesforce publicaba para ese modelo pasaban de largo.
Rediseñamos el proceso sobre las capacidades estándar y acompañamos la salida con un esquema de adopción gradual: tres acciones mínimas el primer mes, seis el segundo y nueve el tercero.
Los usuarios clave ya están capacitados con guías visuales por rol. Lo que se espera ahora es el uso real de licencias que la empresa pagaba desde antes, sobre un modelo que sí recibe cada release.
Revisa tu org antes de que llegue Spring '27
Responde con sí o no:
¿Hay una persona con nombre que lee cada release y propone qué activar?
¿Sabes qué cambió solo en tu org con Winter '27, como el filtro de perfiles?
¿Tienes un sandbox actualizado donde probar antes de pasar a producción?
¿Ventas y servicio tienen cada uno un usuario que prueba las novedades?
¿Sabes cuánta lógica de tu org vive en código a medida que reemplaza funciones estándar?
¿Tus flows tienen escenarios de prueba guardados para repetir después de cada release?
¿Tu equipo comercial usa hoy alguna novedad de las últimas tres releases?
Si dudaste en más de dos, tu org está recibiendo releases que nadie aprovecha. El orden para corregirlo se repite cada cuatro meses, así que la segunda vuelta cuesta menos que la primera.
Cada cuatro meses vuelve la misma decisión
Spring '27 va a llegar con su propia lista de novedades, varias de ellas apagadas y alguna que se activa sola.
Puedes seguir descubriéndolas por los reclamos de tus usuarios, o puedes darle a cada release un dueño, un sandbox y un criterio para elegir.
Si tu org está sana, el trabajo es operar ese ciclo con disciplina, que es lo que hace nuestro Soporte Especializado. Si la personalización acumulada no deja entrar lo nuevo, conviene partir por medir cuánto de tu org puede volver al estándar.
Si quieres que alguien tome esa decisión contigo en cada release, conversemos:
