Automatic Subtask Chaining in GLPI with SubTask Flow

Chain support steps in GLPI: when a task is completed, SubTask Flow creates the next one automatically based on the chosen solution. Template-based setup, cycle protection and audit SQL.

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:

  1. Identifies the child templates linked to that solution;
  2. Creates the child TicketTasks in the same ticket's timeline;
  3. 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

  1. Standardize the solution list in the module configuration (for example: "hardware", "software", "no fault"). Treat it as a closed vocabulary, not free text.
  2. Open the parent TaskTemplate and link the child templates in the chaining tab.
  3. For each child, define which solution triggers it.
  4. 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.
  5. 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)

ApproachWhen to useLimit
One-off task (manual)Ad-hoc processes, low volume, no repetitionDoes not standardize or trace
Native task templateA single repeated step with fixed contentDoes not chain the next step
SubTask FlowConditional sequence of tasks within the same ticket, triggered by the solutionScope is the ticket; does not open new tickets
GLPI ProjectDelivery with milestones, multiple tickets, Gantt and deadlinesHigh overhead for a short flow
Business rulesRouting and assignment at ticket creationDoes 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.

Frequently Asked Questions

No. GLPI offers task templates (TaskTemplates) to standardize the content of each step, but it does not automatically trigger the next one. SubTask Flow adds the parent-child relationship between templates, so completing one task creates the next.

Yes. The trigger fires when the technician marks the task as Done and picks the solution. Child subtasks are created in the same ticket timeline, without waiting for a cron job or external process.

The module runs a depth-first search (DFS) over the template graph before accepting a link. If the new link closes a cycle (A generates B, B generates A), it is rejected with an explanatory message at save time.

Almost always the chosen solution does not match the one configured on the link - a case or naming difference - or no child template is linked to that solution. Standardize solutions as controlled vocabulary and check the parent template.

Use the module's log tab to see parent, child, solution, technician and timestamps. To monitor hygiene, run SQL over glpi_tickettasks and glpi_tasktemplates filtering by state and by empty assignee to spot orphaned tasks.

Need help?