Para automatizar la baja de usuarios de Microsoft 365, construya flujos de salida en Microsoft Entra ID Lifecycle Workflows que se disparen a partir de un atributo de fecha en el objeto de usuario y no a partir de un ticket que alguien tiene que acordarse de abrir. Usted fija employeeLeaveDateTime en la cuenta y Entra ejecuta un flujo previo a la baja antes del último día, un flujo de baja el día mismo y un flujo posterior a la baja después, cada uno con tareas integradas como Disable User Account, Remove user from all groups, Remove all licenses for user y Delete User Account. El disparador es una fecha, el ámbito es una regla y la ejecución deja un historial que puede enseñar a un auditor. Esta guía recorre toda la construcción, dice con honestidad qué licencia hace falta y cubre las cuatro cosas que no hará por usted.
La persona que se fue y conservó una licencia durante cuatro meses
Empiece por el fallo que esto pretende arreglar, porque casi nunca es un fallo técnico. Alguien se marcha. El servicio de soporte bloquea el inicio de sesión el último día, le cae encima algo urgente y el resto de la secuencia no ocurre nunca. Cuatro meses después la cuenta sigue habilitada, sigue en tres grupos de seguridad, sigue reteniendo un asiento completo y sigue contando en la factura.
Merece la pena hacer la cuenta con sus propios números en lugar del punto de referencia de nadie. Una organización de 250 usuarios con una rotación habitual quizá pierda 30 personas al año. Si cada baja se completa con seis semanas de retraso de media, eso son unos 3,5 meses de asiento desperdiciados por persona que sale, es decir, unos 105 meses de asiento al año. A £22 el asiento son algo más de £2,300; a £35 se acercan a £3,700. Cambie cualquier dato de entrada y la respuesta se mueve, que es justo el sentido: su responsable financiero puede comprobar esa suma mentalmente.
El coste es la parte que abre una conversación de presupuesto. El riesgo es la parte que abre una conversación de dirección. Quien se va con pertenencias a grupos activas conserva todo lo que esos grupos conceden, y con entre 50 y 600 usuarios esa misma persona suele tener además credenciales compartidas, una pertenencia a un Team con datos de clientes dentro y un buzón que nadie ha leído desde que se marchó. La automatización importa aquí no porque los pasos manuales sean difíciles, sino porque un proceso manual que se ejecuta 30 veces al año se saltará al menos una vez, y usted no sabrá cuál.
Qué cubre realmente el borrado del centro de administración
Conviene ser preciso sobre el punto de partida manual. En el centro de administración de Microsoft 365, en Users then Active users, seleccionar a una persona y elegir Delete user ejecuta un paquete completo: puede retirar las licencias, dar a alguien acceso al OneDrive y al correo y luego eliminar la cuenta. Es un flujo realmente útil para una sola persona que se va y no debería darle vergüenza usarlo.
Lo que no es es un proceso. No hace nada hasta que un humano lo abre, trata a todo el mundo igual sin importar el puesto ni el departamento, no produce más registro que el del log de auditoría que nadie reconocería como evidencia, y no puede ejecutarse una semana antes del último día ni treinta días después. Acertar con el orden de las operaciones también importa más de lo que se espera, porque retirar una licencia antes de haber resuelto el buzón pierde datos. La lista de comprobación para dar de baja usuarios de Microsoft 365 expone esa secuencia paso a paso y sigue siendo la referencia correcta de cómo se hace bien. Este artículo trata de conseguir que esa secuencia se ejecute sola.
La cuestión de la licencia, respondida antes de planificar nada
Tenga esto claro antes de diseñar nada, porque decide si el resto del artículo le resulta relevante.
Lifecycle Workflows exige licencias de Microsoft Entra ID Governance o de Microsoft Entra Suite. No está en Microsoft Entra ID P1, no está en Microsoft Entra ID P2, y por tanto tampoco está en Microsoft 365 E3 ni E5 por el plan de Entra que incluyen. Microsoft Entra ID Governance es una suscripción aparte que se apoya sobre un plan que cualifique, y Microsoft ha sido explícito en que no se añadirán nuevas capacidades de gobernanza de identidades al SKU de Entra ID P2.
También necesita licencias suficientes para cubrir a cada usuario miembro dentro del ámbito del flujo, más quien lo configura, y no un único asiento de administrador. El propio ejemplo trabajado de Microsoft es un flujo previo a la baja con un ámbito de 50 usuarios, que necesita 51 licencias. Para una organización de 300 usuarios que da de baja a 30 personas al año, eso cambia la forma del caso de negocio: no está licenciando a 30 personas que salen, está licenciando a toda la población que cubre el ámbito del flujo.
Hay una prueba. Un Global Administrator en un tenant comercial que ya tenga un producto que cualifique, como Microsoft Entra ID P1, y que no la haya probado antes, puede iniciarla desde el centro de administración de Microsoft 365 en Billing then Purchase services, buscando Microsoft Entra ID Governance y seleccionando Details then Start free trial. Esa es la forma honesta de probar los flujos de más abajo contra su propio tenant antes de que nadie firme nada.
Construya el flujo de salida
Crear un flujo en el centro de administración de Microsoft Entra siempre parte de una plantilla, y hay 14 integradas. Cuatro importan para las salidas, y la razón de que sean cuatro es que dar de baja no es un solo momento.
Pre-Offboarding of an employee se ejecuta de forma predeterminada siete días antes de employeeLeaveDateTime, con Remove user from selected groups y Remove user from selected Teams. Este es el que la gente se salta y luego lamenta: es donde saca a alguien del grupo de nóminas y del Team de finanzas mientras todavía está ahí para hacer el traspaso.
Offboard an employee se ejecuta en la fecha de salida misma, con Disable User Account, Remove user from all groups y Remove user from all Teams. Este es el flujo que cierra la puerta.
Post-Offboarding of an employee se ejecuta después de la fecha de salida, con Remove all licenses for user, Remove user from all Teams y Delete User Account. Este es el flujo que detiene la facturación del asiento, y el desfase que elija aquí es el número más caro de todo el diseño.
Real-time employee termination no tiene condición de ejecución alguna. Es solo bajo demanda, lleva Remove user from all groups, Delete User Account y Remove user from all Teams, y existe para el caso de quien sale del edificio hoy mismo.
El catálogo de tareas más amplio es donde afina cada uno. Junto a las tareas anteriores incluye Revoke all refresh tokens for user, Remove all access package assignments for user, Send email to manager before user's last day, Send email on user's last day y Send email to user's manager after their last day. Que la revocación de sesiones sea una tarea integrada merece señalarse, porque muchas guías de baja todavía la presentan como algo que hay que scriptar.
Dos plantillas más merecen mención aunque no dependan estrictamente de una salida: Pre-Offboard inactive users y Offboard inactive users se disparan por inactividad de inicio de sesión en lugar de por una fecha de salida, con 90 y 120 días de forma predeterminada. Son la prima automatizada del informe de nuestra guía sobre cómo encontrar usuarios inactivos de Microsoft 365, y capturan las cuentas que nunca tuvieron fecha de salida porque nadie llegó a avisar de que la persona se había ido.
Programación, ámbito y el atributo del que pende todo
Tres detalles de configuración deciden si esto funciona en la práctica.
El atributo no es gratis. employeeLeaveDateTime no se rellena solo. Viene del aprovisionamiento dirigido por RR. HH., de Microsoft Entra Connect o de un script que lo escribe a través de Microsoft Graph. Escribirlo en un contexto delegado exige el rol Global Administrator junto con los permisos User.Read.All y User-LifeCycleInfo.ReadWrite.All, que es un listón más alto que el de la mayoría de las tareas de informes y conviene plantearlo pronto a quien sea dueño de su integración con RR. HH. Si nadie fija la fecha, no se ejecuta nada, y el flujo parecerá roto cuando simplemente está ocioso.
La programación es opcional y hay que activarla. Los flujos nuevos vienen habilitados de forma predeterminada, pero la programación no, así que un flujo puede quedarse ahí con aspecto correcto y no dispararse jamás. Una vez programados, los flujos se evalúan en un intervalo para todo el tenant que de forma predeterminada es cada tres horas y puede fijarse entre 1 y 24 horas, en ID Governance then Lifecycle workflows then Workflow settings del centro de administración de Microsoft Entra. Necesita al menos el rol Lifecycle Workflows Administrator para cambiarlo.
Las ejecuciones bajo demanda ignoran sus condiciones de ejecución. Ejecutar un flujo bajo demanda aplica sus tareas al usuario cumpla o no el ámbito y el disparador. Eso es exactamente lo que quiere para un despido con efecto inmediato y exactamente lo que no quiere mientras prueba, así que pruebe contra una cuenta que esté dispuesto a perder.
Una buena noticia sobre los plazos: si la fecha de salida se fija tarde, por ejemplo porque el sistema de RR. HH. se actualizó a posteriori, Lifecycle Workflows aun así intentará procesar al usuario siempre que la configuración se complete dentro de los tres días siguientes al momento de procesamiento previsto. Ese comportamiento de recuperación no se aplica a la opción Time based attribute V2, actualmente en versión preliminar pública.
Cinco movimientos. Entra automatiza el uno, el dos, el tres y el cinco. El cuarto es el que decide si alguien se fía de los otros cuatro.
Las cuatro cosas que no hará
Lifecycle Workflows gobierna la identidad. Dar de baja en Microsoft 365 es más amplio que la identidad, y estas cuatro lagunas siguen siendo suyas.
El buzón. No hay ninguna tarea que convierta un buzón de usuario en un buzón compartido, y la trampa del orden es real: el buzón todavía tiene que estar licenciado en el momento en que lo convierte, así que esto tiene que ocurrir antes de que el flujo posterior a la baja retire la licencia, no después.
Los archivos. Dar a un responsable acceso al OneDrive de quien se va es una tarea del centro de administración de SharePoint. Nada en las plantillas de salida lo toca.
El dispositivo. Retire y Wipe viven en el centro de administración de Microsoft Intune, y ninguna tarea de ciclo de vida llega hasta ahí. Los informes programados de Intune son la vía práctica para demostrar qué dispositivos de quienes se van llegaron de verdad a registrarse y a cumplir.
La factura. Remove all licenses for user libera la asignación. No reduce la cantidad de una suscripción ya pagada, así que el ahorro solo llega a su factura cuando alguien actúa en la renovación. Si la licencia venía de licenciamiento basado en grupos, la pertenencia al grupo es lo que retiene el asiento, y por eso las tareas de grupo y la tarea de licencia van en el mismo flujo.
Aquí está el script para la primera laguna, dimensionado para ejecutarse una vez por persona que sale, en la ventana entre el último día y la ejecución posterior a la baja.
# Fills the gaps Lifecycle Workflows does not cover, before the licence is removed
Connect-ExchangeOnline
Connect-MgGraph -Scopes "User.RevokeSessions.All"
$Leaver = "leaver@contoso.com"
$Manager = "manager@contoso.com"
# Belt and braces: end every active session now rather than waiting for token expiry
Revoke-MgUserSignInSession -UserId $Leaver
# Convert while the mailbox is still licensed, or the conversion is not available
Set-Mailbox -Identity $Leaver -Type Shared
Add-MailboxPermission -Identity $Leaver -User $Manager -AccessRights FullAccess -InheritanceType All
Add-RecipientPermission -Identity $Leaver -Trustee $Manager -AccessRights SendAs -Confirm:$false
Write-Host "$Leaver converted to shared and delegated to $Manager"
Léalo antes de ejecutarlo. Revoke-MgUserSignInSession es redundante si su flujo de baja ya lleva la tarea de revocación, e inofensivo si lo lleva. La conversión mantiene el correo y el calendario accesibles hasta 50 GB sin un asiento de pago, que es lo que hace seguro dejar que el flujo retire la licencia un día después. No elimine la cuenta mientras el buzón compartido esté en uso, porque la cuenta lo ancla.
Si esa secuencia le parece algo que preferiría ver ejecutándose de forma continua en lugar de recordarla persona a persona, una prueba de 14 días de EtherInsights muestra las mismas comprobaciones contra su propio tenant.
El límite honesto de automatizar esto
Lifecycle Workflows es bueno. También es un mecanismo, no un resultado, y tres cosas separan lo uno de lo otro.
Alguien tiene que asumirlo. Un flujo sin dueño se desvía: la regla de ámbito deja de coincidir con un departamento al que le cambiaron el nombre, alguien edita una plantilla en una semana ajetreada y nadie se da cuenta hasta que una baja no hace nada en silencio. El historial del flujo le da la materia prima, consultable por usuarios, ejecuciones y tareas, pero la materia prima no es una revisión.
Alguien tiene que producir la evidencia. Su auditor, su evaluador de Cyber Essentials y el cuestionario de seguridad de su mayor cliente hacen la misma pregunta con palabras distintas: demuéstreme que el acceso se retiró dentro del plazo declarado, para estas personas concretas, en estas fechas. Eso es un trabajo de informes encima del flujo, no un subproducto suyo.
Y alguien tiene que seguir la recuperación hasta la factura. El asiento que libera el flujo solo es un ahorro cuando baja la cantidad de la suscripción. Entre esos dos hechos hay una fecha de renovación y una conversación con finanzas, que es donde muere en silencio la mayor parte del trabajo de recuperación. Nuestra guía sobre cómo demostrar el ahorro en costes de nube explica por qué ese último paso necesita un antes y un después en lugar de una afirmación.
Nada de esto es un argumento contra construir los flujos. Constrúyalos este mes. Es un argumento para tener claro que la automatización resuelve el problema de la ejecución y deja el problema de la responsabilidad exactamente donde estaba.
Dónde encaja EtherInsights
EtherInsights es la consola que se sitúa por encima de todo esto. Comprueba las bajas de forma continua en lugar de por ticket, saca a la luz a quienes se han ido y siguen habilitados o siguen con licencia como hallazgos con un propietario con nombre y una acción siguiente, y conserva el antes y el después para que una recuperación llegue a su revisión financiera como evidencia y no como una afirmación. Donde tenga Lifecycle Workflows, le dice si los flujos hicieron de verdad aquello para lo que los diseñó. Donde no lo tenga, porque la licencia de gobernanza aún no está aprobada, le da la misma visibilidad sin ella.
La gestión de licencias y baja de usuarios de Microsoft 365 ejecuta el ciclo de altas, cambios y bajas como un solo proceso a través de varios tenants, con el trabajo de asientos latentes de cómo encontrar licencias sin usar en la misma vista. Cuesta £0.79 por usuario activo con una prueba de 14 días, así que puede medir la distancia entre sus fechas de salida y sus retiradas de licencia antes de comprometerse a nada, que suele ser la cifra que zanja la discusión.
Fije bien la fecha de salida, construya los tres flujos programados, escriba el script del buzón y ponga una revisión mensual en el calendario. Si esa revisión se sigue aplazando, ha encontrado la limitación real, y nunca fue la herramienta.
Explore la gestión de licencias y baja de usuarios de Microsoft 365 para ver las comprobaciones de salida, la recuperación de licencias y el rastro de evidencia tratados como un proceso continuo en lugar de un flujo que nadie vigila.