Collaborate, Innovate, Automate

La Retirada de las Alertas de SharePoint, Ya Está Aquí, y el Inventario No Es la Parte Difícil

22 de julio de 2026 Gobierno Guías

Nota: probablemente debería haber escrito sobre este tema antes. Las Alertas de SharePoint se están retirando. Probablemente ya has visto el aviso, lleva meses apareciendo en el cuadro de diálogo clásico "Enviarme un aviso".

La creación de nuevas alertas ya está bloqueada desde enero de 2026. La retirada completa, es decir, que cada alerta restante deje de funcionar de forma permanente, ocurre en julio de 2026. Un inventario de las alertas existentes es bastante fácil de crear, y puede ayudar a establecer quién creó cada alerta, permitiendo a los administradores contactar con esas personas para identificar si las alertas siguen siendo relevantes y necesitan alguna funcionalidad de sustitución.

Escanear las alertas no basta

Las alertas son por usuario, por lista, y completamente invisibles para cualquiera excepto la persona que las creó y el propietario del sitio. Una lista a escala de tenant que diga "existen 500 alertas" no te dice casi nada útil por sí sola. No te dice cuáles de esas 500 son el resumen diario de un equipo de cumplimiento normativo frente a una prueba olvidada de alguien hace tres años.

Hay varias cosas que complican esto más de lo que parece a primera vista.

Los usuarios pueden consultar sus alertas aquí: https://yourtenant.sharepoint.com/sites/yoursite/_layouts/15/mysubs.aspx

Las alertas ya llevan caducando silenciosamente desde octubre de 2025. El despliegue por fases de Microsoft implica que cualquier alerta que nadie haya renovado activamente en los últimos meses ya ha dejado de funcionar, en silencio, sin ninguna notificación para nadie. Si tu escaneo devuelve muchas menos alertas de las que esperabas, eso no significa necesariamente que al script se le esté escapando algo. Puede significar que el propio mecanismo de caducidad de la retirada ya hizo parte de la limpieza antes de que llegaras a comprobarlo. Vale la pena saberlo de todos modos, porque cambia cuánta urgencia queda para lo que sí sigue en pie.

Las alertas están delimitadas a nivel de web, no de colección de sitios. Un escaneo que solo comprueba el web raíz de cada sitio se perderá cualquier cosa registrada en un subsitio clásico por debajo de él. Si tu tenant todavía tiene jerarquías de subsitios en lugar de sitios modernos planos, eso es una brecha real, no un fallo del script, y merece la pena tenerla en cuenta explícitamente en lugar de asumir que un escaneo limpio significa un tenant limpio.

La API no te avisa cuando te está bloqueando. Probé a añadir una alerta de prueba con PnP PowerShell para confirmar de primera mano el comportamiento de la retirada. La interfaz es honesta al respecto, un aviso rojo claro y un botón Aceptar deshabilitado. PowerShell no lo fue. Falló con un error genérico, "Item and item.ParentList cannot both be null", sin mencionar alertas, sin mencionar la retirada. Si estás automatizando algo contra las alertas ahora mismo y te encuentras exactamente con ese mensaje, no es tu código. Es el bloqueo, simplemente sin explicarse.

Una comprobación manual rápida primero

Antes de ejecutar nada a escala de tenant, vale la pena confirmar qué tiene registrado realmente un solo sitio. Este es el fragmento que hay que ejecutar primero, en un sitio, antes de cualquier otra cosa:

Connect-PnPOnline -Url "https://yourtenant.sharepoint.com/sites/yoursite" -Interactive -ClientId "<your-client-id>"
Get-PnPAlert -AllUsers | Select-Object Title, ID, EventType, Filter, AlertTime, Status

Eso por sí solo suele ser revelador. Muestra exactamente qué hay registrado, a quién pertenece, y si sigue activo (Status: On) o ya ha caducado. Ejecútalo en dos o tres sitios que conozcas bien antes de confiar en que un barrido a escala de tenant te va a decir algo.

El inventario, a escala de tenant

La comprobación de un solo sitio anterior no escala más allá de un puñado de sitios. Para un barrido completo del tenant, a continuación se enlazan dos scripts:

  • Un script de configuración de la lista, que crea la lista de SharePoint de destino con todas las columnas necesarias para capturar los resultados del escaneo (quién creó cada alerta, qué lista vigila, cómo se entrega, cuándo se escaneó, y un campo de estado para el flujo de revisión que viene después).
  • El script de escaneo en sí, que recorre cada sitio del tenant, eleva temporalmente la cuenta en ejecución a Administrador de la Colección de Sitios solo el tiempo justo para ver las alertas de otros usuarios en ese sitio (los permisos habituales de Administrador de SharePoint no otorgan esto por defecto, es una barrera deliberada de Microsoft), escanea, y luego retira esa elevación inmediatamente después, con éxito o con fallo. Escribe un elemento por sitio en la lista, incluyendo los sitios sin ninguna alerta, de modo que la propia lista demuestra qué sitios se comprobaron realmente en lugar de dejar huecos que tendrías que asumir como limpios.

Ambos están disponibles en la biblioteca de scripts.

Una vez tengas la lista, no actúes solo con ella

Esta es la parte que es fácil saltarse cuando vas contrarreloj. El inventario te dice que una alerta existe y a quién está registrada. No te dice si todavía importa.

Antes de migrar o eliminar nada, contacta primero con el propietario de la alerta. La alerta de alguien sobre "Lista de seguimiento de incidencias: Todos los elementos" podría ser un resto ignorado de un proyecto que terminó hace dos años. También podría ser lo único que se interpone entre cumplir un plazo normativo y no cumplirlo. La lista no puede distinguir entre ambos casos. Solo puede hacerlo la persona que la configuró.

Si tras esa conversación decides que una alerta se puede eliminar con seguridad, es un comando de una sola línea:

Connect-PnPOnline -Url "https://yourtenant.sharepoint.com/sites/yoursite" -Interactive -ClientId "<your-client-id>"
Remove-PnPAlert -Identity "<alert-id-from-your-inventory>"

Haz esto alerta por alerta, tras confirmación, no como un barrido masivo. El límite de julio de 2026 va a eliminarlas de todos modos. Lo único que controlas ahora mismo es si las personas que dependen de ellas se enteran por ti, con calma, con antelación, o por una notificación que falta después de los hechos.

¿Necesitas ayuda para inventariar y migrar las Alertas de SharePoint antes del límite de julio de 2026?

Ponte en contacto y lo revisamos juntos.


Cameron Griffiths is a Microsoft 365 consultant based in Valencia, Spain, specialising in SharePoint Online, Power Automate and Microsoft 365 for business. camerongriffiths.com