NexTool Solutions

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 the technician records the solution of a task in the timeline, the next one is created automatically based on that answer.

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 records the solution in the parent task's timeline (or, if the template has no condition, marks the task as "Done"), 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, duration and assignee (technician and group) 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. A conditional child requires the parent template to have "Information" as its default state.
4. Make sure every child template has a responsible group or technician and a duration filled in - this is the field that causes the most pain later.
5. Test on a staging ticket before releasing to production: create a test parent task for each possible solution, record the solution in the timeline and confirm that the right child is born with the correct data.

Cycle detection

Chaining without a guard becomes a trap. A template A that generates B, which generates C, which loops back to A, would recreate the same tasks on every lap, and the flow would never end. When a new link is saved, the module runs a depth-first search (DFS) over the template graph. If it finds a cycle, it shows a warning with the loop path, but the link stays saved: removing it is up to whoever configures the flow. Only linking a template to itself is blocked. That is why 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 ticket, the parent task, the generated child task, who triggered it, who completed it 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 task?" - 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 from which task.

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)

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.

Reviewed by the NexTool Solutions team.