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. A category can have several flows, even on the same trigger, run in the order set on each one.
• 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 another flow in the same operation, 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 open a test ticket from a template right on the configuration screen, before releasing the flow to production. Note that the test creates a real ticket and requires its own permission.

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. Validate the template on the test tab before leaving the flow active: there is no separate switch for the engine, and with the module active every active flow already runs.

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 was the old rule of one active flow per category, which made two processes on the same category fight over the same slot; since version 2.0 a category accepts several flows, run in the order set on each one. 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 activating the flow.

Compatibility

• GLPI: 11
• Plan: PAID
• Plugin: NexTool base 6.11.0 or later

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

Reviewed by the NexTool Solutions team.