Asking a manager to log into GLPI just to approve a ticket is friction that costs SLA hours. Anyone who runs a service desk knows the scene: the approval email arrives, the manager reads it on their phone, has no password at hand, and the ticket sleeps until someone chases it by phone.
The problem
Approval workflows, solution validation and satisfaction surveys all depend on an action from people who rarely open GLPI: the manager who authorizes a purchase, the external client who confirms the issue is fixed, the end user who rates the service. In native GLPI, all of these happen inside the authenticated interface. For anyone without an account - or with one but no memory of the password - that becomes a real barrier.
The outcome is predictable: stalled approvals, tickets frozen waiting for a reply that never comes, and the team spending time on manual follow-up. The satisfaction survey is the extreme case: response rates fall close to zero when login is required, because the user simply gives up at the authentication screen. It is not a lack of willingness to answer; it is one extra step nobody wants to clear.
How it works
NexTool's Mail Interactions module adds notification tags to GLPI. The moment the email is queued, the module swaps each tag for a unique, ephemeral URL. The recipient clicks, lands on a public page, confirms the action, and GLPI is updated - no login screen, no account.
- Approve or reject validations - the tags
##ticket.approve_link##and##ticket.reject_link##go into the validation notification template. The approver opens the link, optionally writes a justification, and confirms. - Validate or reopen the solution -
##ticket.validate_link##closes the ticket when the requester confirms it is resolved;##ticket.reopen_link##reopens it for further work. - One-click satisfaction survey -
##ticket.satisfaction_link_1##through##ticket.satisfaction_link_10##already carry the pre-selected rating; the user clicks the score straight from the email and, if they wish, leaves a comment. - Tickets, Changes and Problems - the same tags exist per item type:
##ticket.*##,##change.*##and##problem.*##(for Problem, only validate and reopen). - Single-use, time-limited tokens - each link is valid for a configurable period (7 days by default) and is invalidated on first use, preventing repeat clicks or reuse.
- Mandatory justification, when it makes sense - you can require a comment on rejection, on reopening, or on satisfaction scores below a threshold, improving the quality of the record.
Module vs. native GLPI
What changes in practice, compared with GLPI's default behavior:
| Action | Native GLPI | With Mail Interactions |
|---|---|---|
| Approve / reject validation | Approver must sign in and open the ticket | One click on the email link, confirm on the public page |
| Confirm / reopen solution | Requester acts inside the authenticated interface | Direct link in the proposed-solution email |
| Satisfaction survey | Answered in the GLPI interface or portal | Pre-selected score, one-click response |
| User without a GLPI account | Cannot act | Acts via the public page, without consuming a user seat |
| Link security | Authenticated GLPI session | 256-bit single-use token, with expiry and HTTPS |
A real example: the tags in the notification template
The tags go into the HTML body of the validation notification template (Setup > Notifications > Notification templates). A typical snippet of the body:
<!-- Template: "Ticket validation" event -->
<p>Hello ##validation.validator##,</p>
<p>Ticket <strong>##ticket.title##</strong> (##ticket.id##)
is awaiting your approval.</p>
<p style="text-align:center">
<a href="##ticket.approve_link##"
style="background:#22c55e;color:#fff;padding:12px 20px;border-radius:6px">
Approve
</a>
<a href="##ticket.reject_link##"
style="background:#ef4444;color:#fff;padding:12px 20px;border-radius:6px">
Reject
</a>
</p>
<p>The links expire in 7 days and can be used only once.</p>
When the email is generated, Mail Interactions replaces each tag with a tokenized URL. For illustration only, the format is this:
https://support.yourcompany.com/plugins/nextool/ajax/module_ajax.php
?module=mailinteractions&file=approve.php
&token=Yc7d...opaque-256-bit-token...&a=approve
The token encodes nothing about the ticket: it is a random value that only exists because it was issued and stored on the server. There is no way to forge, guess, or reuse it. The main settings live in the module's Configure tab:
# Setup > NexTool > Modules > Mail Interactions > Configure
token_ttl_days = 7 # link lifetime, in days
force_https_links = 1 # always generate https:// URLs
require_reject_description = 1 # require a justification on reject
require_reopen_description = 1 # require a justification on reopen
satisfaction_max_stars = 5 # survey scale (5 or 10)
satisfaction_require_comment_below = 3 # require a comment if score < 3
What we learned in support operations
Running GLPI for clients, the most common mistake we see is not technical, it is configuration: putting the approval tags in the wrong notification template. If you place ##ticket.approve_link## in a template that also fires on other events (for example "Ticket updated"), the link ends up in emails where there is no pending validation - and the recipient gets a link that only leads to an error page. The right approach is to use those tags only in the validation-event template. It is simple, but it accounts for much of the support we open about "the link doesn't work".
The second lesson came from an infrastructure detail. Email security appliances - Microsoft Safe Links, Mimecast and the like - pre-open the links in messages to scan them before the user clicks. If the approval were executed on the bare GET of the link, those bots would "approve" the ticket on their own, producing phantom approvals. That is why the module never acts on the click: the link opens a confirmation page and the action is only committed on a POST with its own form token. The pre-fetch bot sees the page but does not confirm the form, so the single-use token stays intact. That architectural choice prevented improper approvals at a client on corporate Office 365 - a problem that only shows up in production, never in the test environment.
A fine detail worth knowing: on solution validation, when the entity has a configured closure delay (GLPI's solvedelay), the module uses that delay as the link lifetime instead of the 7-day default. The link then lives exactly as long as the ticket can still be reopened - no more, no less.
How to enable it
- Have the NexTool plugin installed on your GLPI 10 or 11.
- Go to Setup > NexTool > Modules.
- Enable Mail Interactions and click Configure to set the token lifetime, forced HTTPS and the justification rules.
- In Setup > Notifications > Notification templates, edit the validation (or solution/satisfaction) template and add the tags you want to the body.
- Trigger a test validation and check the email: the links should point to
/plugins/nextool/ajax/module_ajax.phpwith a token in the URL.
Who it is for - and when not to use it
Mail Interactions suits any organization that uses approval workflows in GLPI and suffers delays because approvers rarely access the system. It is especially valuable for service desks that serve end users and external clients without a GLPI account - they validate solutions and answer surveys with no access barrier at all.
When not to use it: if your security policy requires every approval to be traced through an authenticated login with MFA (financial compliance, high-value approvals), the public page does not replace that control - in that case, keep the approval inside GLPI's authenticated session. The module removes friction; it is not a substitute for a legally binding electronic signature.
Compatibility
- GLPI: 10.0+ and 11.0+
- Plugin: NexTool (Mail Interactions module, base 4.3.4 or later)
- Supported items: Ticket, Change and Problem (Problem: validate/reopen only)
- Plan: on demand
Next step
Mail Interactions is part of NexTool, an ecosystem of modules that extend GLPI without code customization. Talk to the team for a demo in your environment.
This content was produced with the help of artificial intelligence and reviewed by the Nextool Solutions team.