Algunos procesos siempre generan un ticket derivado - y cada vez que se olvida la etapa, el proceso falla en silencio. El módulo Ticket Flow de NexTool convierte ese encadenamiento en automatización: cuando un ticket cumple un criterio, crea el ticket siguiente a partir de una plantilla nativa de GLPI, sin intervención humana.
El problema
Muchas categorías de ticket siguen siempre el mismo guion. Cuando se abre un ticket de "Contratación de Servicio", debería nacer automáticamente uno de "Aprobación Financiera". Cuando un ticket de "Mantenimiento" se resuelve, debería aparecer una "Encuesta de Calidad". En GLPI de fábrica esa orquestación vive en la memoria del técnico - cuando se acuerda. El resultado es conocido: etapas saltadas, procesos incompletos y auditoría imposible, porque no hay registro de los subprocesos que se deberían haber abierto.
Seamos honestos sobre lo que GLPI ya hace. Las reglas de negocio de ticket (RuleTicket) son excelentes para enrutar, asignar y categorizar - pero actúan sobre el propio ticket que se está creando o actualizando. Ninguna regla nativa crea un ticket nuevo a partir de otro. Esa es justamente la brecha que Ticket Flow cubre.
Cómo funciona Ticket Flow
El módulo permite configurar flujos que disparan la creación de un ticket nuevo cuando un ticket original cumple un criterio. Cada flujo se vincula a una categoría ITIL y a un evento disparador, y usa las plantillas de ticket nativas de GLPI para generar el ticket derivado:
- 3 disparadores configurables - ticket creado, ticket resuelto y ticket cerrado. Cada categoría solo admite un flujo activo, lo que elimina ambigüedad sobre qué regla vale.
- Integración con TicketTemplate - el ticket hijo nace de una plantilla nativa de GLPI, heredando categoría, título, descripción, grupos y prioridad ya configurados en la plantilla.
- Motor vía hooks nativos - la ejecución es automática mediante los hooks item_add e item_update de Ticket, sin depender de cron ni de acción manual.
- Guarda anti-loop - un mecanismo interno impide que el ticket generado dispare el motor de nuevo, cortando el riesgo de recursión infinita.
- Registro de ejecución - cada activación se registra con enlace al ticket original y al ticket generado, creando trazabilidad completa.
- Pestaña de prueba - se puede simular la creación de un ticket a partir de una plantilla en la propia pantalla de configuración, antes de liberar el flujo en producción.
Por qué la plantilla de ticket es el corazón del flujo
Como el ticket hijo se genera a partir de un TicketTemplate, la calidad del flujo depende por completo de cómo esté rellenada la plantilla. Antes de poner un flujo en producción, conviene auditar los campos predefinidos de tus plantillas. La consulta siguiente lista las plantillas de ticket y sus campos predefinidos - si el campo de grupo o de responsable está vacío, el hijo nace huérfano:
-- Plantillas de ticket y sus campos predefinidos.
-- Ticket Flow copia estos valores en el ticket hijo.
-- Campo esencial en blanco (grupo/responsable) = hijo huerfano.
SELECT tt.id AS plantilla_id,
tt.name AS plantilla,
tp.num AS campo_num,
tp.value AS valor_predefinido
FROM glpi_tickettemplates tt
LEFT JOIN glpi_tickettemplatepredefinedfields tp
ON tp.tickettemplates_id = tt.id
ORDER BY tt.name, tp.num;
Cada fila es un campo predefinido de la plantilla. El valor de num es la opción de búsqueda de GLPI (título, categoría, grupo solicitante, grupo asignado, prioridad). Una plantilla sin grupo asignado genera un ticket hijo que nadie ve en la cola - y el proceso se traba justo donde debería avanzar.
Ticket Flow vs funciones nativas de GLPI
| Necesidad | Función nativa de GLPI | Ticket Flow |
|---|---|---|
| Crear un ticket derivado automáticamente | No existe - las reglas de negocio solo editan su propio ticket | Sí, por categoría + disparador |
| Reutilizar valores predefinidos de campos | TicketTemplate, aplicado manualmente en la apertura | TicketTemplate aplicado al hijo de forma automática |
| Disparar por resolución o cierre | No hay disparador para generar otro ticket | Disparadores: creado, resuelto, cerrado |
| Evitar el bucle de creación | No aplica | Guarda anti-recursión integrada |
| Rastrear el vínculo padre e hijo | Historial suelto en el ticket | Registro que enlaza el ticket padre al hijo |
Cómo activarlo
- Instala el plugin NexTool en tu GLPI.
- Accede a Configuración > NexTool > Módulos.
- Activa Ticket Flow y haz clic en Configurar.
- En la pestaña Flujos, crea un flujo eligiendo la categoría, el disparador y la plantilla del ticket hijo.
- Activa el motor de automatización en la pestaña de configuración y valida el comportamiento en la pestaña de prueba antes de producción.
Para quién es - y cuándo no usarlo
Ticket Flow es para equipos con procesos estructurados donde abrir un ticket es condición para que otro empiece: gestión de cambios, contrataciones, proyectos y procesos de calidad, donde olvidar una etapa tiene impacto real en la operación y en la auditoría.
No es la herramienta correcta cuando lo que necesitas es encadenar tareas dentro del mismo ticket (para eso existe un flujo de subtareas), ni cuando la lógica es simplemente asignar o categorizar el propio ticket - eso ya lo resuelven las reglas de negocio nativas. Ticket Flow gana valor justamente cuando un proceso debe generar otro ticket, con dueño y plazo propios.
Lo que aprendimos sosteniendo esto
En la sustentación, el error número uno de Ticket Flow nunca está en el motor: está en la plantilla del ticket hijo sin grupo asignado - el hijo nace sin dueño y desaparece de la cola. El segundo es olvidar que solo un flujo por categoría queda activo, así que dos procesos que dependen de la misma categoría pelean por la misma plaza. El tercero es el más traicionero: el disparador "cerrado" también se activa cuando GLPI cierra el ticket por sí solo, mediante la rutina de cierre automático por inactividad (el cron de autoclose). Vimos a un cliente amanecer con una tanda de tickets hijos creados de madrugada, porque un lote de tickets antiguos fue cerrado por la rutina y cada cierre activó el flujo. La recomendación que estandarizamos: reserva el disparador "cerrado" para procesos que realmente deban correr al cierre, prefiere "resuelto" cuando la intención es reaccionar a la resolución, y valida siempre la plantilla hija en la pestaña de prueba antes de encender el motor.
Compatibilidad
- GLPI: 10.0+ y 11.0+
- Plan: PAID
- Plugin: NexTool 3.x+
Ticket Flow forma parte de NexTool, ecosistema de módulos para expandir GLPI sin personalización de código. Habla con el equipo para una demostración.
Este contenido fue producido con ayuda de inteligencia artificial y revisado por el equipo de Nextool Solutions.