El rol de autoservicio del manager define qué puede ver y proponer un manager sobre los datos de las personas de su equipo. Como el del empleado, no es una funcionalidad aparte: es un rol de permisos con su grupo, sus permisos y su población objetivo. Lo que cambia es la población: en lugar del propio usuario, la población objetivo se define en relación con quien recibe el rol, normalmente sus subordinados directos.
Según la academia oficial, el autoservicio del manager se usa para actualizar la información del puesto, cambiar el salario e iniciar traslados. La academia también señala que las transacciones del manager que afectan el puesto y la compensación suelen configurarse con una aprobación adicional, y que los aprobadores se determinan con los flujos de trabajo configurados. Por eso el rol del manager y los flujos de la L3 se diseñan juntos.
La academia arma el rol del manager con tres entidades con fecha efectiva: la información del puesto, la compensación y las relaciones del puesto. A cada una le da ver actual y ver historial en todos los campos, y Editar/Insertar en el vínculo de edición. A eso se suma un permiso que no está en las entidades sino en Datos del empleado > Acciones de RR. HH.: Actualizar registros de empleo, que es el que hace aparecer el botón de acciones. Sin ese permiso, el manager puede tener todos los permisos de edición y no encontrar por dónde empezar.
Hay algo que el rol del manager no debería tener: Editar/Insertar, Corregir o Eliminar en las acciones del bloque. Esos permisos habilitan la ventana de historia, donde se eligen a mano el evento y el motivo y no se dispara ningún flujo. La academia llama a esa vía la edición de RR. HH. y la reserva para administradores.
El rol también lleva permisos sobre los motivos de evento que el manager puede usar, en Datos del empleado > Motivos de evento. Como vimos en la L2, ese permiso filtra la lista de motivos del botón de acciones y, desde 1H 2025, también la de eventos.
En el caso del curso, el rol se llama AR_Autoservicio manager y se otorga al grupo AR_Managers, que hoy tiene un solo miembro: Martín Gómez, manager de todos los empleados de la filial desde la U4 L3. Su población objetivo son los subordinados directos de quien recibe el rol. En la información del puesto, Martín puede proponer cambios de puesto, grado, ubicación y modalidad de trabajo. Tiene permiso sobre AR_PROMO y AR_TRASL.
En un cliente con muchos managers, mantener un grupo a mano no escala: el paso de otorgamiento permite dar el rol directamente a los managers. En AR01, con un solo manager, el grupo alcanza.
El Video 1.2 arma el rol y lo prueba con un sustituto de Martín. El Tip 1.2 explica por qué Martín es un mal candidato para probar solo este rol: también integra AR_Equipo RR. HH. y tiene el rol de RR. HH. de la filial, que le da más permisos y tapa cualquier falta.
