Automatizar la creación de tickets en GLPI con Ticket Flow

Los procesos que siempre generan un ticket derivado dejan de depender de la memoria del técnico. El módulo Ticket Flow de NexTool crea el ticket siguiente automáticamente cuando un ticket se crea, resuelve o cierra - a partir de plantillas nativas de GLPI, con guarda anti-loop, registro padre e hijo y SQL de auditoría de las plantillas.

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. Una categoría puede tener varios flujos, incluso en el mismo disparador, ejecutados en el orden definido en cada uno.
  • 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 otro flujo en la misma operación, 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 abrir un ticket de prueba a partir de una plantilla en la propia pantalla de configuración, antes de liberar el flujo en producción. Atención: la prueba crea un ticket real y exige un permiso propio.

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

NecesidadFunción nativa de GLPITicket Flow
Crear un ticket derivado automáticamenteNo existe - las reglas de negocio solo editan su propio ticketSí, por categoría + disparador
Reutilizar valores predefinidos de camposTicketTemplate, aplicado manualmente en la aperturaTicketTemplate aplicado al hijo de forma automática
Disparar por resolución o cierreNo hay disparador para generar otro ticketDisparadores: creado, resuelto, cerrado
Evitar el bucle de creaciónNo aplicaGuarda anti-recursión integrada
Rastrear el vínculo padre e hijoHistorial suelto en el ticketRegistro que enlaza el ticket padre al hijo

Cómo activarlo

  1. Instala el plugin NexTool en tu GLPI.
  2. Accede a Configuración > NexTool > Módulos.
  3. Activa Ticket Flow y haz clic en Configurar.
  4. En la pestaña Flujos, crea un flujo eligiendo la categoría, el disparador y la plantilla del ticket hijo.
  5. Valida la plantilla en la pestaña de prueba antes de dejar el flujo activo: no hay un interruptor aparte para el motor, y con el módulo activo todo flujo activo ya se ejecuta.

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 era la regla antigua de un flujo activo por categoría, que hacía que dos procesos de la misma categoría pelearan por la misma plaza; desde la versión 2.0 la categoría acepta varios flujos, ejecutados en el orden definido en cada uno. 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 activar el flujo.

Compatibilidad

  • GLPI: 11
  • Plan: PAID
  • Plugin: base NexTool 6.11.0 o superior

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.


Revisado por el equipo de NexTool Solutions.

Preguntas Frecuentes

El módulo Ticket Flow de NexTool configura flujos que abren un ticket nuevo cuando un ticket se crea, resuelve o cierra. El ticket hijo se genera a partir de una plantilla nativa de GLPI (TicketTemplate), heredando categoría, grupos y prioridad.

No. Las reglas de ticket (RuleTicket) actúan solo sobre el ticket que se está creando o actualizando - asignan, categorizan, definen SLA. Ninguna regla nativa crea un ticket nuevo a partir de otro. Esa es justamente la brecha que Ticket Flow cubre.

No. Una guarda anti-loop impide que el ticket generado por el flujo dispare otro flujo en la misma operación. Aun así, atención al disparador de cierre: también se activa en el cierre automático por inactividad (el cron de autoclose), así que resérvalo para procesos que deban correr al cierre.

No. La configuración se hace por la interfaz de GLPI, seleccionando categoría, disparador (creación, resolución o cierre) y plantilla de ticket. El punto crítico es rellenar bien la plantilla hija, sobre todo el grupo asignado, para que el ticket generado no nazca huérfano.

?Necesitas ayuda?