Salesforce apaga en febrero la contraseña olvidada

El escenario, sin dramatismo

Un proceso nocturno de facturación pide un token a Salesforce, sincroniza los pedidos con el ERP y deja la operación lista para la mañana. Corre a las 2 a.m., sin pantalla, sin nadie mirando.

El 20 de febrero de 2027 ese proceso pide el token y recibe una respuesta: invalid_grant. El job termina con error, lo escribe en un log que nadie revisa, y sigue con su rutina. A la mañana siguiente los pedidos están en el CRM pero no en el ERP. Al tercer día alguien pregunta por qué las cifras no cuadran.

Nada se rompió: hubo un cambio de fecha programado por el proveedor y una integración que nadie tenía inventariada.

Lo que cambia el 20 de febrero

Salesforce retira el flujo OAuth 2.0 de usuario y contraseña para Connected Apps. La nota de release lo enmarca como el cierre de un mecanismo de autenticación: la actualización, en sus palabras, "romperá todas las integraciones de Connected Apps que usen este flujo". La fecha de entrada en vigor es el 20 de febrero de 2027.

Vale ser preciso con la fuente, porque importa para el uso que le dará su equipo. La nota oficial de Salesforce se consultó, pero la página entrega solo un indicador de carga al abrirla sin sesión, así que el cuerpo completo no se pudo leer en crudo. El texto citado proviene del extracto de esa nota, y la fecha está confirmada por tres fuentes independientes que cubren la notificación. Si su equipo va a actuar sobre esto, abra la release update en Setup con su sesión: se llama "Retirement of OAuth 2.0 Username-Password Flow for Connected Apps".

Lo que ese flujo hace, en una frase, es pedir un token enviando el usuario, la contraseña y el security token de una persona. Es exactamente lo que un script de hace cinco años aprendió a hacer y nunca dejó de hacer.

Por qué el fallo es silencioso

Hay tres razones por las que esto no se va a anunciar solo en su operación.

No hay banner. El cambio llega por release notes, no por una notificación dirigida al administrador. Nadie le va a enviar un correo la semana antes.

La pantalla obvia no las lista. Según el análisis técnico publicado por Salesforce Time el 15 de octubre, Salesforce no muestra las integraciones con flujo usuario-contraseña en Connected Apps OAuth Usage, incluso cuando esas integraciones tienen sesiones activas. Es decir: el lugar donde un Director de TI buscaría la respuesta no la tiene. Nadie miró mal: el tablero está incompleto por diseño.

La fecha ya se movió una vez. Salesforce anunció el cambio en Spring '26 y planeaba aplicarlo con Winter '27. Lo postergó al 20 de febrero de 2027. Si alguien de su equipo vio el aviso hace meses y lo archivó, tiene razones para creer que ya se ocupó. Además, las organizaciones creadas en Summer '26 o después ya tienen el flujo bloqueado, así que el comportamiento no es uniforme.

Las cuatro capas donde vive esa credencial

El problema es que en una empresa mediana esa credencial aparece en cuatro lugares distintos, y cada uno tiene un dueño diferente.

El middleware o la plataforma de integración. Es el caso más común y el más fácil de encontrar, si alguien sabe dónde buscar. Suele tener un usuario de servicio dedicado, y a veces hasta documentación.

El script propio. Un Python de 2019 que hizo alguien del equipo, que sigue corriendo en un servidor y que nadie volvió a tocar porque "funciona". El usuario puede ser nominal, y esa persona quizá ya no trabaja en la empresa.

El paquete de un proveedor. Una aplicación de terceros que se conecta a su CRM y le pide cargar usuario y contraseña en una pantalla de configuración. Aquí la credencial vive fuera de su control y el dueño del riesgo técnico es el vendor, aunque el dueño del incidente sea usted.

El usuario nombrado. Una cuenta de una persona real usada para automatizar. Cuando esa persona cambia su contraseña, la integración sigue igual hasta que expira el token, y después falla sin que nadie relacione las dos cosas.

Por qué "revisar el Login History" no cierra el caso

El atajo que sugiere la documentación es útil: buscar eventos con subtipo OauthUsernamePassword en el historial de inicios de sesión, filtrar los últimos meses y buscar grant_type=password en el código del middleware.

Pero tiene límites que conviene conocer antes de dar el tema por cerrado. El historial guarda aproximadamente seis meses y muestra hasta 20.000 registros. Una integración que corre una vez por trimestre, o una que se ejecuta solo en cierres, puede no aparecer en esa ventana. Y entonces "no encontré nada" solo prueba que no ocurrió en el período visible.

El calendario completo de la capa de integración

Este retiro no es un evento aislado, y tratarlo como tal es lo que deja las cosas para después. Winter '27 llegó a disponibilidad general el 12 de octubre de 2026 y trae, en las mismas release notes, tres fechas que caen sobre la misma capa:

• 20 de febrero de 2027: fin del flujo OAuth usuario y contraseña.
• 1 de junio de 2027: fin del login() por SOAP. Las integraciones que lo usan necesitan además un permiso nuevo que ya se está exigiendo.
• Verano de 2027: fin de los platform events de volumen estándar, que pasan a ser high-volume por defecto.

Un solo inventario resuelve los tres. Tres ejercicios separados, en cambio, cuestan tres veces lo mismo y llegan tarde a cada fecha.

Lo que el proveedor comunica y lo que le obliga a hacer

Hay un contraste que vale la pena mirar. El anuncio oficial de Winter '27, publicado el 12 de octubre de 2026, está dedicado por completo a agentes. No menciona el retiro del flujo OAuth, ni el de SOAP, ni el de los platform events.

Así funcionan las plataformas grandes. El material promocional habla de lo nuevo. Lo que obliga a mover a los clientes vive en las notas técnicas. Pero para un Director de TI, la consecuencia es concreta: lo que el vendor destaca y lo que le va a exigir trabajo no son la misma lista, y la segunda no llega por el mismo canal.

Cinco preguntas para el primer barrido

No hace falta esperar a febrero ni contratar nada para empezar. Con estas cinco preguntas su equipo puede hacer el primer barrido esta semana:

1. ¿Qué jobs o scripts piden un token hoy? Cualquier proceso que envíe usuario, contraseña y security token es candidato directo.
2. ¿Con qué usuario corre cada uno? ¿Es un usuario de servicio dedicado o la cuenta de una persona real?
3. ¿Quién es el dueño de cada integración? Una persona con nombre, no un área. Si no hay nadie, ese es el hallazgo.
4. ¿Qué paquete de un tercero depende de este flujo? Porque ahí la corrección no está en su código: está en la configuración que el proveedor le pide cargar.
5. ¿Qué se rompe primero si el token no llega? Facturación, inventario, conciliación de pagos. El orden importa, porque define por dónde empezar.

Y hay un detalle que suele pasar inadvertido hasta que ya migraron: al cambiar de flujo, cambia el usuario con el que corre la integración. Si ese nuevo usuario no tiene exactamente los mismos accesos, la autenticación pasa y las operaciones fallan igual. El error deja de ser invalid_grant y se convierte en un problema de permisos que aparece más tarde y cuesta más diagnosticar.

Un proyecto, no una configuración

La migración del flujo no es una casilla que se cambia en Setup. Requiere decidir qué mecanismo reemplaza al anterior, crear o ajustar el usuario de servicio con permisos mínimos, probar en un ambiente separado y verificar que las operaciones sigan funcionando después de autenticar.

Ese inventario de conexiones, usuarios y jobs es el tipo de trabajo que Byxel hace bajo su modelo de Ingeniería de Autor: alguien con nombre responde por cada conexión y por lo que se rompe si esa conexión desaparece.

Para seguir leyendo: el apagón de Salesforce y las dependencias ocultas, el fin de soporte de SAP y las integraciones que destapa y el costo de mantener integraciones conectadas a mano.

La fecha es del proveedor. El inventario es suyo. Y es la única parte que se puede empezar hoy.

Si tu equipo no puede contestar hoy a nombre de quién corre cada integración con el CRM, ese es el primer entregable. En Byxel mapeamos el inventario de conexiones, usuarios y jobs antes de que la fecha llegue. Escribinos por WhatsApp y lo revisamos con tu equipo técnico.