Cómo automatizar la baja de empleados con Freshservice
September 21, 2026
Cuando llega el último día de un empleado, Recursos Humanos cierra su expediente y sigue adelante, pero la huella digital que deja esa persona rara vez se borra a tiempo. Un portátil que no se devuelve, una cuenta de Slack que permanece activa o una credencial de administrador para un sistema que nadie recuerda haber otorgado siguen funcionando mucho después de que la persona haya abandonado la empresa. Cada uno de estos cabos sueltos representa un riesgo y, en la mayoría de las compañías, nadie se encarga de identificarlos todos.
La baja de empleados se encuentra en un punto crítico: Recursos Humanos la inicia, TI la ejecuta y el CISO es quien debe dar explicaciones cuando una auditoría detecta una cuenta que debería haberse desactivado meses atrás. Freshservice soluciona esta brecha convirtiendo la baja en un flujo de trabajo estructurado y automatizado, en lugar de una lista de tareas que alguien debe recordar completar, coordinando a Recursos Humanos, TI y cualquier otro equipo que gestione el acceso del empleado desde un registro único.
Para los directores de TI y gerentes de ITSM que evalúan cuánto de este proceso se puede automatizar realmente, la respuesta honesta es que casi todo, siempre que el flujo de trabajo esté diseñado en torno a los sistemas que un empleado utiliza habitualmente. Las siguientes secciones explican cómo funciona el activador, qué se automatiza en cuanto a accesos y activos, y cómo crear una lista de verificación de cierre que supere cualquier auditoría.
La baja manual falla por una razón predecible: depende de que una persona recuerde una lista de pasos bajo presión, generalmente mientras asume también la carga de trabajo del empleado que se marcha. Una lista de verificación en un documento compartido no se actualiza cuando se añade una nueva herramienta SaaS a la infraestructura de la empresa, y no impide que alguien marque un paso como completado sin haberlo hecho realmente. El resultado es una discrepancia entre lo que el proceso de baja debería cubrir y lo que realmente hace.
Esa discrepancia aumenta con el tamaño de la empresa. Un equipo de diez personas puede sobrevivir a un paso omitido porque alguien se da cuenta rápidamente. Una empresa de quinientas personas con una docena de herramientas SaaS, varias unidades compartidas y acceso a sistemas basado en roles no tiene esa red de seguridad, y el tiempo entre el último fichaje del empleado y su última credencial activa puede extenderse durante semanas.
El flujo de trabajo comienza donde se toma la decisión, no donde TI se entera por casualidad. Cuando Recursos Humanos envía una notificación de renuncia, finalización de contrato o despido, ya sea directamente en Freshservice o a través de una integración con el sistema de gestión de RR. HH. (HRIS), esa acción inicia automáticamente el proceso de baja, sin que TI necesite un ticket adicional o un mensaje solicitando que alguien comience el proceso.
El marco de trabajo Journeys de Freshservice está diseñado precisamente para este tipo de traspaso interdepartamental: coordina tareas entre Recursos Humanos, TI y finanzas a partir de un único activador, de modo que el mismo evento que cierra el expediente del empleado en RR. HH. abre los tickets que TI necesita gestionar. Los flujos de trabajo programados pueden añadirse a ese activador, permitiendo programar pasos específicos, como el corte de acceso en el último día o recordatorios anticipados, en el momento preciso en lugar de ejecutar todo a la vez.
La proliferación de accesos es la parte de la baja con más probabilidades de fallar, ya que un solo empleado puede acumular cuentas en proveedores de identidad, plataformas en la nube y herramientas departamentales específicas sobre las que TI no siempre tiene visibilidad total. Una solicitud de baja puede activar flujos de trabajo de revocación y acciones de desactivación en sistemas de identidad conectados como Active Directory u Okta, junto con Microsoft 365 y cualquier otro sistema vinculado a la integración.
El valor aquí no es solo la velocidad, sino la integridad. Un flujo de trabajo que revoca el acceso según un perfil de rol o departamento definido detecta sistemas que un técnico de TI ocupado podría pasar por alto un viernes por la tarde, y cada acción se registra automáticamente, lo cual es tan importante para la pista de auditoría como para la seguridad misma.
Más allá del acceso, existen equipos y software de pago registrados a nombre del empleado que se marcha, y dejar estos asuntos sin resolver supone un costo económico. Freshservice puede detectar automáticamente los activos y el software vinculados al empleado que causa baja, generando tickets de recuperación y revocando el acceso al software sin que el equipo de TI tenga que cruzar manualmente el inventario de activos con la lista de bajas de RR. HH.
Esa misma detección se integra directamente en la gestión de licencias de software, ya que una licencia que queda sin asignar tras la salida de un empleado representa un gasto innecesario o, peor aún, una plaza que se reasigna silenciosamente sin pasar por el departamento de compras. Recuperar el activo y reclamar la licencia en el mismo flujo de trabajo cierra ambas brechas a la vez, en lugar de tratarlas como tareas de limpieza independientes.
Un proceso de baja bien diseñado suele automatizar:
La automatización solo se gana la confianza de un CISO o de un auditor externo si deja constancia. Cada paso que ejecuta Freshservice (creación de tickets, revocación de acceso, devolución de activos) queda registrado con una marca de tiempo y el usuario o flujo de trabajo que lo realizó, lo que convierte el proceso de baja en una prueba documental en lugar de una simple afirmación.
Ese registro es la misma base que respalda las auditorías de cumplimiento de ITSM: si un auditor pregunta si el acceso de un empleado que se marchó fue revocado dentro del plazo establecido, no tiene por qué fiarse de la palabra de TI. El historial del ticket y las marcas de tiempo responden a la pregunta directamente. Integrar la lista de verificación dentro del flujo de trabajo, en lugar de en un documento separado, significa que la lista y el rastro de auditoría son el mismo elemento.
El proceso de baja suele diseñarse de forma aislada, pero se parece tanto al de incorporación que tratarlos como un proceso conectado ahorra un esfuerzo técnico considerable. El mismo marco de Journeys , la misma lógica basada en roles y, a menudo, las mismas integraciones impulsan ambos extremos del ciclo de vida del empleado, lo que significa que la automatización del ciclo de vida del empleado cubre todo el arco, desde el aprovisionamiento del primer día hasta la revocación del último, en lugar de tratar cada etapa como un proyecto independiente.
Desarrollar el proceso de baja después de haber consolidado el de alta tiene una ventaja práctica: la mayor parte del trabajo de integración, como las conexiones con AD, Microsoft 365 y el sistema de RR. HH. de la empresa, ya está hecho. Ampliarlo para cubrir las salidas es, en gran medida, una cuestión de definir el flujo de trabajo inverso en lugar de crear una infraestructura nueva.
Los equipos que se inician en esto suelen obtener mejores resultados si comienzan por la brecha de mayor riesgo en lugar de intentar automatizar cada paso a la vez. Para la mayoría de los directores de TI, esa brecha es la revocación de accesos, ya que mantener una credencial activa tras la salida es el escenario con mayor exposición directa a riesgos de seguridad, seguido de cerca por la recuperación de activos, dado que el hardware no devuelto es el fallo más visible y el que se escala con mayor frecuencia.
Una vez que estos dos procesos están automatizados y registrados de forma fiable, ampliar el flujo de trabajo para cubrir notificaciones, documentación y la secuencia completa de procesos resulta una expansión de menor riesgo en lugar de una construcción desde cero. Los paneles que realizan el seguimiento de las solicitudes de alta y baja en Freshservice facilitan ver qué salidas siguen pendientes y qué pasos, si los hay, se están retrasando.
La gestión de bajas nunca será la parte más visible de un programa de ITSM, pero es uno de los pocos procesos en los que un solo paso omitido se convierte en un auténtico incidente de seguridad. Para los directores de TI que evalúan dónde resulta más rentable la automatización, cerrar la brecha entre el último día de un empleado y su última credencial activa es un excelente punto de partida. Los equipos que deseen diseñar un flujo de trabajo de bajas en Freshservice para su propio entorno pueden ponerse en contacto con nosotros para analizar cómo sería esa configuración.
