IT processes rarely fit into a single step. Diagnosis leads to execution, execution leads to validation, and each stage only makes sense after the result of the previous one. In stock GLPI, every one of those tasks is born from the technician typing it by hand, which makes standardization impossible as soon as volume grows. The SubTask Flow module chains these stages: when a task is completed, the next one is created automatically based on the chosen solution.
Why creating the next task by hand does not scale
Many support flows are predictable: analyze, execute, validate, communicate. GLPI offers task templates (TaskTemplates) to standardize the content of each step, but it has no idea that one step should generate the next. The result is familiar: the technician opens the right template, copies the assignee and due date, and creates the following task by hand. In an environment with dozens of technicians, this produces three chronic problems: forgotten steps, divergent data across equivalent tickets, and no traceability for "why does this task exist". When an audit asks whether validation was done, the answer depends on each technician's individual discipline, not on a designed process.
How SubTask Flow chains tasks by solution
The module creates hierarchical relationships between TaskTemplates. A parent template points to one or more child templates, and each child can be conditioned on a specific solution. When the technician marks the parent task as "Done" and picks the solution, the module runs three steps:
- Identifies the child templates linked to that solution;
- Creates the child TicketTasks in the same ticket's timeline;
- Copies content, category, estimated time and assignee defined in the child template.
The configuration lives in the template, not in the ticket. You adjust the flow once and it applies to every ticket that uses that template, without touching business rules or external automations. That is the difference between documenting a process and having the system execute it.
Step-by-step configuration
- Standardize the solution list in the module configuration (for example: "hardware", "software", "no fault"). Treat it as a closed vocabulary, not free text.
- Open the parent TaskTemplate and link the child templates in the chaining tab.
- For each child, define which solution triggers it.
- Make sure every child template has a responsible group or technician and an estimated time filled in - this is the field that causes the most pain later.
- Test on a staging ticket before releasing to production: complete the parent task, pick every possible solution and confirm that the right child is born with the correct data.
Cycle protection
Chaining without a guard becomes a trap. A template A that generates B, which generates C, which loops back to A, would create tasks indefinitely and freeze the ticket timeline. Before accepting a new link, the module runs a depth-first search (DFS) over the template graph. If the link closes a cycle, it is rejected with an explanatory message instead of letting the problem blow up in production. The same discipline applies as with any automation: keeping chains short and readable makes diagnosis easier when something goes off script.
Traceability: the log tab
Automation without a record is a black box. SubTask Flow keeps an execution history with the parent template, the generated child template, the chosen solution, the responsible technician and timestamps. In an audit, this answers the most common question - "was this subtask created by a person or by the flow, and from which decision?" - without relying on anyone's memory. It is also the first place to look when a client reports that "the step disappeared": the log shows whether the trigger fired and with which solution.
Diagnostics: auditing the flow in SQL
Silent automation demands active monitoring. The query below lists still-open subtasks that were born without an assignee, the classic symptom of an incomplete child template. Run it on a read replica or during a low-usage window:
-- Open subtasks (state=1) with no assigned technician or group.
-- Flags a child TaskTemplate with empty users_id_tech/groups_id_tech.
SELECT t.id AS ticket,
tt.id AS task_id,
tmpl.name AS template,
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;
In GLPI, state = 1 is "To do" and state = 2 is "Done". If this list grows every week, the problem is not the module: it is a child template published without an assignee, generating tasks nobody sees in the queue.
When to use it (and when not to)
| Approach | When to use | Limit |
|---|---|---|
| One-off task (manual) | Ad-hoc processes, low volume, no repetition | Does not standardize or trace |
| Native task template | A single repeated step with fixed content | Does not chain the next step |
| SubTask Flow | Conditional sequence of tasks within the same ticket, triggered by the solution | Scope is the ticket; does not open new tickets |
| GLPI Project | Delivery with milestones, multiple tickets, Gantt and deadlines | High overhead for a short flow |
| Business rules | Routing and assignment at ticket creation | Does not manage steps after creation |
The most common field mistake
Maintaining environments with many technicians, the problem that shows up most is not technical, it is modeling. Someone configures the child to fire on the solution "Hardware", but the option the technician actually picks on screen is "hardware" in lowercase - or "HW", in an environment that inherited its vocabulary from another tool. The trigger does not match, the subtask is not created, nobody gets an error, and the execution step simply disappears from the process without a visible trace. The fix we standardized: treat solution strings as controlled vocabulary, all lowercase, documented in a single mapping, and review the child templates every time someone adds a new solution. The second recurring mistake is the child template with no assignee: the task is born orphaned, gets lost in the middle of the timeline and only resurfaces once the SLA has already breached. That is why the SQL query above belongs in the maintenance checklist, not in a one-off audit.
NexTool deploys and maintains GLPI environments with automations like SubTask Flow designed for each client's real operation. Talk to our team to map and automate your team's task flow.
This content was produced with the help of artificial intelligence and reviewed by the Nextool Solutions team.