Paper signatures are still required on many work orders and liability terms. The NexTool SignaturePad module brings that step inside GLPI: the user signs by mouse or touch, the system stamps the signature onto the PDF and files the signed document linked to the ticket - no printing, scanning or leaving the support flow.
The problem
Service desk teams that issue work orders always hit the same bottleneck when collecting a signature: generate the PDF, print it, sign on paper, scan and archive. Every manual step is a point of failure - a lost document, a crooked scan, a file saved on the technician's desktop and disconnected from the ticket that produced it. In remote support the physical signature simply never happens, and the customer has no way to sign without an ICP-grade digital certificate or extra software.
The result is an audit gap: the ticket was closed, but the proof of delivery lives outside GLPI. When someone needs the signed order months later, the file hunt begins.
How SignaturePad works
The whole flow happens inside GLPI, with no external dependencies:
- Configurable base PDF - the administrator uploads the PDF template in the module settings; it is stored as a native GLPI Document.
- Canvas capture - on the signing page the user signs with the mouse on desktop or with a finger on tablet and phone, installing nothing.
- Automatic stamping - the system stamps the captured signature onto the last page of the PDF using FPDI + TCPDF, generating a new file.
- Linked archiving - the signed PDF is saved as a Document and linked to the source document via a native relation, preserving traceability.
- Controlled access - the signing page requires GLPI login, so the signer is an identified user in the system.
Combined with the OrderService module, the Sign PDF button appears right on the ticket's Work Order tab. After signing, the document is attached to the ticket via Document_Item automatically, with no manual step.
In practice, the technician finishes the job, collects the signature right there - with the customer present or through a sent link - and the ticket is closed with the evidence already attached. No loose PDF in an email or lost in a network folder nobody finds later.
There is a clear gain for teams working with field SLAs: the signature at delivery acts as an acceptance milestone, and because the document stays pinned to the ticket, any later audit finds the evidence without relying on the memory of whoever handled the call.
SignaturePad vs native GLPI
| Need | Native GLPI | With SignaturePad |
|---|---|---|
| Handwritten signature on the ticket | Does not exist | Canvas by mouse or touch |
| Stamping the signature onto the PDF | Manual, outside GLPI | Automatic (FPDI + TCPDF) |
| Linking the document to the ticket | Manual attachment | Automatic Document_Item |
| Signing in remote support | Not feasible | Internal signing link |
| Traceability and audit | Depends on technician discipline | Document always on the ticket |
How to enable
- Install the NexTool plugin in your GLPI.
- Go to Setup > NexTool > Modules.
- Enable the Handwritten Signature (PDF) module and click Configure.
- Upload the base PDF and set the category of the generated document.
- To integrate with work orders, also enable the OrderService module and turn on Work Order integration in the SignaturePad settings.
How to confirm the document is linked
After a test signature, a simple query confirms the signed PDF is actually attached to the ticket - handy while validating the deployment:
-- Documents linked to a ticket (replace 12345 with the ticket ID)
SELECT d.id, d.filename, di.itemtype, di.items_id
FROM glpi_documents_items di
JOIN glpi_documents d ON d.id = di.documents_id
WHERE di.itemtype = 'Ticket'
AND di.items_id = 12345;The detail that only shows up in production support
Deploying in multi-entity clients, the error we saw most is not in the signature capture - it is in the link. GLPI requires the Document to have the same entities_id as the ticket for the Document_Item to be accepted and the attachment to show on the ticket tab. When the signed PDF is generated in a different entity than the ticket (through module configuration inheritance), the file is created but disappears from the technician's view, as if the signature had failed. The rule we now check in every deployment: confirm that the category and entity of the generated document follow the ticket's entity. It is a configuration detail, not a code one, and it fixes the "disappearance" on the first try.
Who it is for (and when not to use it)
SignaturePad suits teams that issue work orders and need customer or technician acceptance, anyone wanting to eliminate the print-sign-scan-archive cycle, and organizations that require an auditable trail with the signed document always attached to the ticket.
It is not the right tool when the requirement is a legally qualified signature under a national PKI or digital certificate - SignaturePad captures the handwritten signature and links it to the GLPI record (who, when, which ticket), which is strong for internal evidence and operational acceptance, but does not replace a qualified signature. For that scenario, integrate a dedicated electronic signature platform.
Compatibility
- GLPI: 10.x and 11.x
- Plan: On demand (PAID)
- Plugin: NexTool 3.x+
Next step
SignaturePad is part of NexTool, the modular plugin for GLPI. For the full work order flow with signature, combine it with the OrderService module. Want to see it running in your environment? Talk to the team.
This content was produced with the aid of artificial intelligence and reviewed by the Nextool Solutions team.
