NexTool Solutions

En GLPI, la "aprobación" nativa es una sola ronda. Solicitas la validación de una o varias personas, defines un porcentaje de aceptación y ya está - no existe un encadenamiento jerárquico donde finanzas solo se consulta después de que el jefe directo haya aprobado. El módulo Approval Flow de NexTool cubre exactamente ese vacío.

El problema: la aprobación jerárquica no existe en el core

En entornos corporativos, aprobar un ticket suele abarcar más de un nivel: el jefe directo lo libera, después finanzas valida el presupuesto, después la dirección lo firma. Es un flujo secuencial - cada paso solo tiene sentido después de que el anterior aprobó. GLPI no modela esto.

Lo que ofrece el core es una única ronda de validación. Abres la pestaña de aprobaciones, eliges validadores (usuarios o grupos) y defines el campo validation_percent - el porcentaje de aprobaciones necesario para que el ticket cuente como validado. Todos los validadores reciben la solicitud al mismo tiempo. No hay orden, no hay "el nivel 2 solo se dispara si el nivel 1 aprueba", no hay un camino distinto para cuando alguien rechaza.

Por qué emular niveles con validation_percent no funciona

En nuestra práctica de soporte y mantenimiento, el diseño que más vemos es intentar forzar una secuencia con el campo de porcentaje: el equipo solicita validación de tres personas y pone 100%, esperando una cadena. No lo es. Los tres reciben la solicitud simultáneamente - la dirección la ve antes de que el jefe directo la haya mirado. Peor aún: si uno rechaza, el ticket pasa a REFUSED, pero las solicitudes de los demás siguen pendientes en su cola "mis validaciones", saturando la vista de cada aprobador. Y no hay forma de decir "si se rechaza, escala a otro nivel" o "si se aprueba, cierra automáticamente con esta plantilla de solución". Lo habitual es que el equipo abandone la función nativa y gestione la cadena por correo, fuera del sistema - lo que mata la trazabilidad y abre una brecha de auditoría.

Cómo funciona Approval Flow

El módulo Approval Flow añade flujos de aprobación multinivel vinculados a las categorías ITIL de los tickets, reutilizando las propias plantillas de validación nativas de GLPI (ITILValidationTemplate) - así, quien aprueba sigue usando la pestaña de aprobaciones estándar, sin pantalla paralela.

• Un flujo por categoría ITIL - cada categoría tiene como máximo un flujo activo, eliminando la ambigüedad sobre qué regla aplica a este ticket.
• Niveles encadenados en árbol - cada nivel tiene caminos independientes para aprobación y rechazo, así defines desenlaces distintos por rama.
• Acción configurable por desenlace - al aprobar o rechazar eliges qué ocurre: no hacer nada, solucionar, cerrar o avanzar al siguiente nivel.
• Solución estandarizada - cuando la acción es solucionar o cerrar, vincular una SolutionTemplate es obligatorio, garantizando el mismo mensaje al solicitante en todos los tickets.
• Disparo automático - al crear un ticket en una categoría con flujo activo, la validación del primer nivel se solicita sola, sin que nadie tenga que recordar abrir la pestaña de aprobaciones.
• Usuarios o grupos por nivel - cada nivel puede apuntar a una persona concreta o a un grupo, usando los mismos destinos que el validador nativo.

Diagnóstico: dónde leer el estado de la aprobación

Antes de diseñar un flujo, conviene saber dónde guarda GLPI el estado nativo - es lo que el módulo orquesta por debajo. Dos consultas resuelven la lectura:

-- GLPI: inspeccionar el estado de validación nativo de un ticket.
-- global_validation y status siguen CommonITILValidation:
--   1 = NONE     (no sujeto a aprobación)
--   2 = WAITING  (en espera)
--   3 = ACCEPTED (aprobado)
--   4 = REFUSED  (rechazado)

SELECT id, name, global_validation, validation_percent
FROM glpi_tickets
WHERE id = 12345;

-- Solicitudes individuales: de forma nativa son todas "pares" en la MISMA ronda.
-- No existe columna de "nivel" ni orden jerárquico.
SELECT tickets_id, status, submission_date, validation_date
FROM glpi_ticketvalidations
WHERE tickets_id = 12345
ORDER BY submission_date;

Si ya intentas simular niveles con varios validadores, la segunda consulta deja el problema a la vista: varias filas en status = 2 (WAITING) al mismo tiempo, sin ninguna columna que exprese orden. Ese es el vacío que cierra el flujo encadenado.

Cómo activarlo

1. Instala NexTool en tu GLPI (10.0+ u 11.0+).
2. Ve a Configuración > NexTool > Módulos.
3. Activa Approval Flow y haz clic en Configurar.
4. En la pestaña Flujos, crea un flujo y vincúlalo a la categoría ITIL deseada.
5. Define los niveles, los aprobadores (usuario o grupo) y la acción de cada desenlace (aprobar/rechazar).
6. Para acciones de solucionar o cerrar, vincula la SolutionTemplate correspondiente.

Para quién es (y cuándo no usarlo)

Encaja en organizaciones que necesitan gobernanza formal de TI: solicitudes de acceso, compras, cambios de infraestructura, cualquier ticket que exija una firma jerárquica con trazabilidad dentro del propio GLPI. También para equipos que operan ITIL y no quieren que su cadena de aprobación viva en un buzón de correo.

No compensa si tu aprobación es de un solo nivel - en ese caso la validación nativa de GLPI ya lo resuelve, y añadir un flujo encadenado solo suma configuración sin ganancia. Tampoco sustituye a un motor de BPM completo: el alcance es la aprobación de tickets, no orquestar procesos arbitrarios con formularios e integraciones externas.

Compatibilidad

• GLPI: 10.0+ y 11.0+
• Plan: PAID
• Plugin: NexTool 3.x+

Siguiente paso

Approval Flow forma parte de NexTool, un ecosistema de módulos que amplía GLPI sin tocar el código del core. Habla con el equipo para ver el flujo multinivel funcionando en tu escenario.

Este contenido se produjo con ayuda de inteligencia artificial y fue revisado por el equipo de NexTool Solutions.