NexTool Solutions

Some processes always spawn a derived ticket - and every time the step is forgotten, the process fails in silence. The NexTool Ticket Flow module turns that chaining into automation: when a ticket meets a criterion, it creates the next ticket from a native GLPI template, with no human intervention.

The problem

Many ticket categories always follow the same script. When a "Service Contract" ticket is opened, a "Financial Approval" one should be born automatically. When a "Maintenance" ticket is resolved, a "Quality Survey" should appear. In stock GLPI that orchestration lives in the technician's memory - when remembered. The result is familiar: skipped steps, incomplete processes and impossible audits, because there is no record of the sub-processes that should have been opened.

Let us be honest about what GLPI already does. Ticket business rules (RuleTicket) are great for routing, assigning and categorizing - but they act on the very ticket being created or updated. No native rule creates a new ticket from another one. That is exactly the gap Ticket Flow fills.

How Ticket Flow works

The module lets you configure flows that trigger the creation of a new ticket when an original ticket meets a criterion. Each flow is tied to an ITIL category and a trigger event, and uses GLPI's native ticket templates to generate the derived ticket:

• 3 configurable triggers - ticket created, ticket resolved and ticket closed. Each category allows only one active flow, which removes any ambiguity about which rule applies.
• TicketTemplate integration - the child ticket is born from a native GLPI template, inheriting category, title, description, groups and priority already configured in the template.
• Engine via native hooks - execution is automatic through the item_add and item_update hooks of Ticket, without relying on a cron job or manual action.
• Anti-loop guard - an internal mechanism stops the generated ticket from firing the engine again, cutting the risk of infinite recursion.
• Execution log - each trigger is recorded with a link to the original ticket and to the generated ticket, creating full traceability.
• Test tab - you can simulate creating a ticket from a template right on the configuration screen, before releasing the flow to production.

Why the ticket template is the heart of the flow

Because the child ticket is generated from a TicketTemplate, the quality of the flow depends entirely on how the template is filled in. Before putting a flow in production, it is worth auditing the predefined fields of your templates. The query below lists ticket templates and their predefined fields - if the group or assignee field is empty, the child is born orphaned:

-- Ticket templates and their predefined fields.
-- Ticket Flow copies these values into the child ticket.
-- An essential field left blank (group/assignee) = orphaned child.
SELECT tt.id            AS template_id,
       tt.name          AS template,
       tp.num           AS field_num,
       tp.value         AS predefined_value
FROM glpi_tickettemplates tt
LEFT JOIN glpi_tickettemplatepredefinedfields tp
       ON tp.tickettemplates_id = tt.id
ORDER BY tt.name, tp.num;

Each row is a predefined field of the template. The value of num is GLPI's search option (title, category, requester group, assigned group, priority). A template with no assigned group generates a child ticket nobody sees in the queue - and the process stalls exactly where it should move forward.

Ticket Flow vs native GLPI features

How to enable it

1. Install the NexTool plugin on your GLPI.
2. Go to Setup > NexTool > Modules.
3. Enable Ticket Flow and click Configure.
4. On the Flows tab, create a flow by choosing the category, the trigger and the child ticket template.
5. Turn on the automation engine in the settings tab and validate the behaviour on the test tab before production.

Who it is for - and when not to use it

Ticket Flow is for teams with structured processes where opening one ticket is a condition for another to start: change management, procurement, projects and quality processes, where forgetting a step has a real impact on operations and audits.

It is not the right tool when you need to chain tasks within the same ticket (a subtask flow does that), nor when the logic is simply to assign or categorize the ticket itself - native business rules already handle that. Ticket Flow earns its place precisely when a process must generate another ticket, with its own owner and deadline.

What we learned maintaining this

In maintenance, Ticket Flow's number-one mistake is never in the engine: it is the child ticket template with no assigned group - the child is born ownerless and disappears from the queue. The second is forgetting that only one flow per category stays active, so two processes that depend on the same category fight over the same slot. The third is the sneakiest: the "closed" trigger also fires when GLPI closes the ticket by itself, through the automatic-closure-on-inactivity routine (the autoclose cron). We once watched a client wake up to a batch of child tickets created overnight, because a lot of old tickets were closed by the routine and each closure fired the flow. The rule we standardized: reserve the "closed" trigger for processes that really must run at closure, prefer "resolved" when you mean to react to resolution, and always validate the child template on the test tab before turning the engine on.

Compatibility

• GLPI: 10.0+ and 11.0+
• Plan: PAID
• Plugin: NexTool 3.x+

Ticket Flow is part of NexTool, an ecosystem of modules to extend GLPI without code customization. Talk to the team for a demo.

This content was produced with the help of artificial intelligence and reviewed by the Nextool Solutions team.