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. 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

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. 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.

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 el motor de nuevo. 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?