Technical support with no signed proof is a verbal promise. The NexTool OrderService module generates a work order PDF directly inside the GLPI ticket, consolidating the ticket data into a document ready to print, sign and archive. When you sustain service desks that work in the field, that document is the difference between "the technician was there" and "the technician was there, and we have the client signature to prove it".
The problem
Many IT teams still issue work orders in a spreadsheet, a Word template or an external system. That creates rework, inconsistent data and a dangerous disconnect: what is recorded in GLPI and what was handed to the client on paper diverge. When an audit arrives, internal or from a corporate client, manually gathering the ticket data, the relevant followups and the approval flow into a single document costs hours that should not exist.
The native option of "printing" the ticket from GLPI produces raw HTML, with no print-ready formatting and no signature support. OrderService fills exactly that gap: one click, one structured PDF.
How OrderService works
After installing and enabling the module, a new Work Order tab appears on every ticket. There, the technician or administrator finds a button to download the PDF with the consolidated information:
- Ticket data - title, ID, category, opening and closing dates.
- Requester and assigned technician - name, email and support group.
- Latest public followups - configurable count; the default includes 2 public followups.
- Related items - assets and equipment linked to the ticket.
- Last solution - the resolution description recorded in GLPI.
- Approval flow - when the ticket went through validation, the section is included automatically.
Sections with no data are omitted: no public followup means no followups section; a ticket with no validation drops the approval section. When the SignaturePad module is active and the integration is enabled, a second button - Sign PDF - lets you capture the handwritten signature inside GLPI and save the signed document linked to the ticket.
OrderService vs GLPI native export
To make clear where the module adds value, it is worth comparing with what GLPI already does on its own:
| Criterion | GLPI native export | OrderService |
|---|---|---|
| Output format | HTML / browser print | Structured PDF, ready to archive |
| Signature field | No | Yes - technician and requester |
| Conditional sections | No | Yes - empty blocks omitted |
| Followups in the document | No fine control | Configurable count |
| Related items | Scattered across tabs | Consolidated in one section |
| Approval flow | Not highlighted | Dedicated section when present |
How to enable
- Install the NexTool plugin in GLPI.
- Go to Setup > NexTool > Modules.
- Find the OrderService card and click Install, then Enable.
- In the module settings, set how many public followups go into the PDF (default: 2).
- Open any ticket, go to the Work Order tab and generate the test PDF.
Audit hygiene: which tickets have no work order
A detail that only surfaces in operations: issuing the work order is easy; ensuring every ticket that needs proof actually has one attached is what passes the audit. When the client asks "prove there was a document for every ticket closed this month", this diagnostic query lists closed tickets with no linked document - adjust the names to your GLPI version:
-- Closed tickets with no attached document (audit hygiene)
SELECT t.id, t.name, t.date_creation
FROM glpi_tickets t
LEFT JOIN glpi_documents_items di
ON di.items_id = t.id AND di.itemtype = 'Ticket'
WHERE t.status = 6 -- 6 = Closed
AND t.is_deleted = 0
AND di.id IS NULL
ORDER BY t.date_creation DESC;
Sustaining a client that works in the field, the technician had to leave a signed proof on site. Before OrderService they filled a parallel Word file and, over time, the paper data drifted from GLPI. The common mistake we warn about is treating the work order as the source of truth: it is a snapshot of the ticket at the moment it was generated. If you edit the ticket later, generate the PDF again - the document does not update itself.
Who it is for (and when not to use it)
The module is ideal for teams that deliver formal documentation at the end of each service, companies whose clients require proof of service, and service desks that work in the field where a paper signed by the client or technician is needed.
When not to use it: if support is fully remote with no formal proof requirement, the PDF becomes a dead artifact nobody opens. And if your process requires a digital signature with legal validity (a qualified certificate or a platform like a signature service), the manual signature field of the PDF does not replace that validity - in that case, combine OrderService with the digital signature module instead of relying on ink on paper.
Compatibility
- GLPI: 10.x and 11.x
- Plan: FREE
- Plugin: NexTool 3.x+
Next step
OrderService is part of NexTool, the modular plugin for GLPI. To add a signature to the generated PDF, combine it with the SignaturePad module. Explore all modules or talk to the team.
This content was produced with the aid of artificial intelligence and reviewed by the Nextool Solutions team.