El botón «Despedir» de Bitrix24 (Alaio) retira al empleado el acceso al portal y nada más: sus negociaciones, tareas, roles de observador y webhooks se quedan con él. Las herramientas nativas de traspaso existen, pero están dispersas, son manuales y no cubren todos los roles. Este artículo repasa qué se queda con el empleado que se va, cómo traspasarlo con las herramientas nativas y dónde los robots son la única vía: registros relacionados del CRM, coejecutores y observadores en las tareas, integraciones que funcionan con el token del empleado y reglas de automatización que dan por hecho que «el empleado está activo».

¿Qué ocurre al despedir y qué queda colgado?

El despido lo hace un administrador o un empleado con el permiso «Despedir empleados» en la estructura de la empresa: «Despedir» en el menú de la lista de empleados o «Acciones → Despedir» en el perfil. El empleado pierde el acceso, pero no se elimina: las tareas, los mensajes y los archivos se conservan, y el perfil pasa a la pestaña «Despedidos», oculta en la lista por defecto. Si el empleado tenía integraciones activas, el portal pregunta si desactivarlas o conservarlas; de eso hablamos más abajo. Todo lo demás queda como estaba: el empleado sigue siendo responsable de negociaciones y contactos, responsable y creador de tareas, observador en fichas, miembro de chats y grupos. Las reglas de automatización y los procesos de negocio que le asignan tareas o le envían notificaciones siguen haciéndolo, hacia el vacío. Así que la baja de un empleado en Bitrix24 no es un botón, sino una lista de comprobación en cuatro áreas: CRM, tareas, integraciones y automatización.

¿Cómo traspaso negociaciones, prospectos, contactos y empresas?

La vía nativa es una acción masiva en la lista: la sección CRM, la vista «Lista», el filtro «Responsable» (para un empleado despedido, la pestaña «Despedidos» en el selector de empleados), marcar las fichas, «Seleccionar acción → Cambiar responsable»; la casilla «Para todos» aplica la acción a todas las páginas de la selección. Esto funciona para prospectos, negociaciones, contactos, empresas, presupuestos y actividades; las facturas se traspasan de una en una desde la ficha de la factura, y si el empleado ya está despedido hay que volver a «contratarlo» temporalmente. Traspasa también los registros cerrados: las llamadas y las notificaciones, cuando el trabajo se retome, llegarán entonces al nuevo responsable. El punto débil de la acción masiva es que no sabe nada de las relaciones: traspasas las empresas y sus contactos y negociaciones se quedan con el empleado que se va. El robot «Cambiar responsable en relacionadas» cierra justo ese hueco: lanzado sobre una empresa, reasigna sus negociaciones o contactos; sobre un contacto, sus negociaciones o empresas; hasta 500 registros por ejecución. Si la base debe repartirse entre un equipo en lugar de entregarse a un solo sucesor, el robot «Asignar responsable: cola / carga de trabajo» elige a la siguiente persona por turno o a la menos cargada; un lanzamiento masivo filtrado por «Responsable» inicia el proceso en todas las negociaciones del empleado a la vez. La reasignación manual, masiva y automática en detalle, en el artículo sobre cambiar el responsable.

¿Cómo traspaso las tareas: responsable, creador, coejecutores y observadores?

Las tareas del empleado que se va las reasigna un administrador: perfil del empleado → pestaña «Tareas» → un filtro como «En curso» → marcar las tareas o «Para todos» → «Seleccionar acción» → «Cambiar responsable» o «Cambiar creador». Un jefe puede reasignar las tareas de sus subordinados directos, pero solo aquellas en las que él es el creador o el responsable. Dos roles que el traspaso nativo no toca: los coejecutores (participantes) y los observadores. El empleado sigue siendo coejecutor en decenas de tareas y observador en cientos, y cada una de ellas sigue esperando una reacción que nunca llega. Desde un proceso de negocio esto se arregla en una sola pasada: «Actualizar tarea por ID» reescribe los campos ACCOMPLICES y AUDITORS con una lista de ID de usuarios, «Cambiar observadores de la tarea» quita a un observador sin tocar al resto, y «Cambiar el creador de la tarea» pasa el rol de creador al sucesor allí donde la acción masiva no está disponible. Quién es quién en una tarea y cómo gestionar estos roles automáticamente, en el artículo sobre observadores y coejecutores.

¿Qué pasa con los webhooks y las integraciones del empleado?

Un webhook ejecuta sus peticiones con los permisos del empleado que lo creó, y su código secreto solo es visible para ese empleado. Así que «los webhooks salientes dejaron de funcionar cuando se fue el empleado» no es un fallo, sino una consecuencia directa. Al despedir, el portal ofrece una elección: «Desactivar integraciones», los webhooks se detienen; «Conservar integraciones», pasan a un usuario del sistema, una copia del empleado, y siguen funcionando. La segunda opción es cómoda, pero el propio portal advierte de que el acceso a los datos a través de esos webhooks se mantiene, y cualquiera que tenga el enlace puede usarlo. El orden razonable: antes del despido, listar qué integraciones, sitios y servicios pasan por los webhooks de esta persona, recrearlos con una cuenta de servicio dedicada con permisos mínimos y solo entonces despedir con las integraciones desactivadas. Si el despido ya se ha producido y algo se ha roto, primero diagnostica el webhook; después, un administrador puede editar el webhook de otro usuario: el código secreto se regenera y el administrador pasa a ser el propietario. Cómo funcionan los webhooks en general, en el artículo de introducción.

¿Cómo quito al empleado de los observadores del CRM y de las reglas de automatización?

En las fichas de negociaciones, prospectos, contactos y empresas el observador es un campo aparte, y el despido no lo limpia. El robot «Gestionar observadores» en modo «Quitar» retira al empleado de la ficha actual; lanzado en masa por un filtro, recorre toda la base. La segunda huella invisible es el empleado dentro de la configuración de la automatización: una regla «Tarea para el empleado» con su nombre, una notificación dirigida a él, un aprobador en un proceso de negocio, un responsable de reserva en la distribución de prospectos. No existe un informe nativo «dónde aparece esta persona en las reglas de automatización», así que hay que recorrer los embudos y las plantillas a mano: filtrar por apellido en la lista de reglas de cada etapa y en los parámetros de las plantillas de procesos de negocio. Para que no se forme esa cola, no escribas a las personas en las reglas por su nombre: toma al destinatario de la estructura; «Obtener el jefe del empleado» devuelve al jefe actual del responsable, no a quien lo era hace seis meses.

¿Cómo construyo una regla con la condición «el empleado está despedido»?

Una petición habitual: que la regla detecte que el responsable ha sido despedido y reasigne la negociación o deje de asignarle tareas. Las condiciones nativas de las reglas comprueban los campos de la ficha, y el indicador de empleado activo no es un campo de la ficha, así que no existe tal condición directamente, y las negociaciones del empleado siguen avanzando por el embudo como cualquier otra. La respuesta práctica no es capturar ese estado, sino evitarlo: traspasar el CRM y las tareas el mismo día del despido con los pasos anteriores, y dirigir los prospectos posteriores no a una persona con nombre, sino a la cola del departamento mediante la distribución de prospectos. Un robot «¿Está activo el empleado?», que recibe un ID y devuelve Y/N y el ID del jefe, todavía no está en la biblioteca de Roboteka; es exactamente el caso para el que crece la biblioteca: describe la tarea, la construimos gratis y la añadimos al catálogo compartido.

Lista de comprobación para la baja de un empleado en Bitrix24

Antes de pulsar «Despedir»: la lista de integraciones y webhooks del empleado, sustituidos por una cuenta de servicio; el traspaso del buzón y del correo de contacto. El mismo día: CRM, en masa desde la lista con «Para todos», y después el robot para los registros relacionados; facturas, de una en una; tareas, responsable y creador desde el perfil, coejecutores y observadores con el robot; observadores del CRM, con el robot; «Desactivar integraciones» en el diálogo de despido. Después: una pasada por las reglas y las plantillas de procesos de negocio que nombran al empleado, y una revisión de los permisos de acceso del sucesor; de lo contrario recibirá negociaciones que no puede ver. La forma más sencilla de mantener todo esto junto es un único proceso de negocio «Baja» sobre un proceso inteligente de RR. HH., donde el empleado y el sucesor son campos del elemento y los pasos son los robots anteriores.

Conclusión

La baja de un empleado en Bitrix24 son cuatro áreas, no un botón. El CRM se traspasa desde la lista; los registros relacionados, con el robot «Cambiar responsable en relacionadas», o entre todo un departamento mediante «Asignar responsable: cola / carga de trabajo»; las tareas, responsable y creador con la acción nativa, coejecutores y observadores mediante «Actualizar tarea por ID» y «Cambiar observadores de la tarea»; los observadores del CRM, «Gestionar observadores»; los webhooks, recreados con una cuenta de servicio antes del despido. Todos los robots están en el catálogo de Roboteka, gratis desde Bitrix24 Market. Si falta un robot para tu paso de la baja, describe la tarea y lo construimos gratis.