Los procesos de TI rara vez caben en un solo paso. El diagnóstico lleva a la ejecución, la ejecución lleva a la validación, y cada etapa solo tiene sentido después del resultado de la anterior. En GLPI de fábrica, cada una de esas tareas nace de que el técnico la escribe a mano, lo que hace imposible la estandarización en cuanto crece el volumen. El módulo SubTask Flow encadena estas etapas: al completar una tarea, la siguiente se crea automáticamente según la solución elegida.
Por qué crear la siguiente tarea a mano no escala
Muchos flujos de atención son predecibles: analizar, ejecutar, validar, comunicar. GLPI ofrece plantillas de tarea (TaskTemplates) para estandarizar el contenido de cada paso, pero no sabe que un paso debe generar el siguiente. El resultado es conocido: el técnico abre la plantilla correcta, copia el responsable y el plazo, y crea la tarea siguiente a mano. En un entorno con decenas de técnicos, esto produce tres problemas crónicos: etapas olvidadas, datos divergentes entre tickets equivalentes y ninguna trazabilidad de "por qué existe esta tarea". Cuando una auditoría pregunta si se hizo la validación, la respuesta depende de la disciplina individual de cada técnico, no de un proceso diseñado.
Cómo SubTask Flow encadena tareas por solución
El módulo crea relaciones jerárquicas entre TaskTemplates. Una plantilla padre apunta a una o más plantillas hijas, y cada hija puede condicionarse a una solución específica. Cuando el técnico marca la tarea padre como "Hecho" y elige la solución, el módulo ejecuta tres pasos:
- Identifica las plantillas hijas vinculadas a esa solución;
- Crea las TicketTasks hijas en la línea de tiempo del mismo ticket;
- Copia contenido, categoría, tiempo estimado y responsable definidos en la plantilla hija.
La configuración vive en la plantilla, no en el ticket. Ajustas el flujo una vez y pasa a valer para todos los tickets que usan esa plantilla, sin tocar reglas de negocio ni automatizaciones externas. Esa es la diferencia entre documentar un proceso y hacer que el sistema lo ejecute.
Configuración paso a paso
- Estandariza la lista de soluciones en la configuración del módulo (por ejemplo: "hardware", "software", "sin defecto"). Trátala como un vocabulario cerrado, no como texto libre.
- Abre el TaskTemplate padre y vincula las plantillas hijas en la pestaña de encadenamiento.
- Para cada hija, define qué solución la dispara.
- Asegúrate de que toda plantilla hija tenga grupo o técnico responsable y tiempo estimado completados - ese es el campo que más duele después.
- Prueba en un ticket de homologación antes de liberar en producción: completa la tarea padre, elige cada solución posible y confirma que la hija correcta nace con los datos correctos.
Protección contra ciclos
El encadenamiento sin freno se convierte en una trampa. Una plantilla A que genera B, que genera C, que vuelve a A, crearía tareas indefinidamente y bloquearía la línea de tiempo del ticket. Antes de aceptar un nuevo vínculo, el módulo ejecuta una búsqueda en profundidad (DFS) sobre el grafo de plantillas. Si el vínculo cierra un ciclo, se rechaza con un mensaje explicativo en lugar de dejar que el problema explote en producción. Vale la misma disciplina que cualquier automatización: mantener las cadenas cortas y legibles facilita el diagnóstico cuando algo se sale del guion.
Trazabilidad: la pestaña de registros
Automatización sin registro es una caja negra. SubTask Flow mantiene un historial de ejecuciones con la plantilla padre, la plantilla hija generada, la solución elegida, el técnico responsable y las marcas de tiempo. En una auditoría, esto responde la pregunta más frecuente - "¿esta subtarea la creó una persona o el flujo, y a partir de qué decisión?" - sin depender de la memoria de nadie. También es el primer lugar donde mirar cuando un cliente reporta que "la etapa desapareció": el registro muestra si el disparador se activó y con qué solución.
Diagnóstico: auditar el flujo en SQL
La automatización silenciosa exige monitoreo activo. La consulta siguiente lista subtareas aún abiertas que nacieron sin responsable definido, el síntoma clásico de una plantilla hija incompleta. Ejecútala en una réplica de lectura o en una ventana de bajo uso:
-- Subtareas abiertas (state=1) sin tecnico ni grupo responsable.
-- Senala una TaskTemplate hija con users_id_tech/groups_id_tech vacio.
SELECT t.id AS ticket,
tt.id AS task_id,
tmpl.name AS plantilla,
tt.state,
tt.users_id_tech,
tt.groups_id_tech,
tt.date_creation
FROM glpi_tickettasks tt
JOIN glpi_tickets t ON t.id = tt.tickets_id
LEFT JOIN glpi_tasktemplates tmpl ON tmpl.id = tt.tasktemplates_id
WHERE tt.state = 1
AND tt.users_id_tech = 0
AND tt.groups_id_tech = 0
AND t.is_deleted = 0
ORDER BY tt.date_creation DESC
LIMIT 200;En GLPI, state = 1 es "Por hacer" y state = 2 es "Hecho". Si esta lista crece cada semana, el problema no es el módulo: es una plantilla hija publicada sin responsable, generando tareas que nadie ve en la cola.
Cuándo usarlo (y cuándo no)
| Enfoque | Cuándo usar | Límite |
|---|---|---|
| Tarea suelta (manual) | Procesos ad-hoc, bajo volumen, sin repetición | No estandariza ni traza |
| Plantilla de tarea nativa | Un paso repetido con contenido fijo | No encadena el paso siguiente |
| SubTask Flow | Secuencia condicional de tareas dentro del mismo ticket, disparada por la solución | El alcance es el ticket; no abre tickets nuevos |
| Proyecto GLPI | Entrega con hitos, múltiples tickets, Gantt y plazos | Sobrecarga alta para un flujo corto |
| Reglas de negocio | Enrutamiento y asignación en la apertura del ticket | No gestiona pasos tras la apertura |
El error de campo más común
En la sustentación de entornos con muchos técnicos, el problema que más aparece no es técnico, es de modelado. Alguien configura la hija para dispararse con la solución "Hardware", pero la opción que el técnico realmente elige en pantalla es "hardware" en minúsculas - o "HW", en un entorno que heredó el vocabulario de otra herramienta. El disparador no coincide, la subtarea no nace, nadie recibe un error, y el paso de ejecución simplemente desaparece del proceso sin dejar rastro visible. La corrección que estandarizamos: tratar las cadenas de solución como vocabulario controlado, todas en minúsculas, documentadas en un único mapeo, y revisar las plantillas hijas cada vez que alguien añade una solución nueva. El segundo error recurrente es la plantilla hija sin responsable: la tarea nace huérfana, se pierde en medio de la línea de tiempo y solo reaparece cuando el SLA ya se rompió. Por eso la consulta SQL anterior entra en el checklist de sustentación, no en una auditoría puntual.
NexTool implanta y sustenta entornos GLPI con automatizaciones como SubTask Flow diseñadas para la operación real de cada cliente. Habla con nuestro equipo para mapear y automatizar el flujo de tareas de tu equipo.
Este contenido fue producido con ayuda de inteligencia artificial y revisado por el equipo de Nextool Solutions.
