Approvals in GLPI without email chains: workflow inside tickets

Approvals in GLPI without email chains: workflow inside tickets

Email approvals work — until they don't. The approver is on holiday, the reply-all chain forks into three threads, somebody types "OK" on a phone without context, and an auditor asks who signed off and when — at which point IT becomes a forensics team in Outlook. Approving inside a GLPI ticket fixes all three problems at once: accountability is visible, history sits in one place, and every step is timestamped in the audit log.

Native validations in GLPI

GLPI has a built-in Validation object that works on tickets (Incident and Request) and on changes (Change). A technician or requester opens the ticket, clicks the Validations → Add tab, picks an approver (a user or a group), and writes a justification. The approver sees the request in the dashboard and in a notification, and replies inside the ticket with one of three states:

  • Waiting — request is open.
  • Granted — approver accepted, optional comment.
  • Refused — justification required (mandatory field).

The ticket can be configured so it cannot transition to Solved without approval. That is the difference from email — the process does not move forward until the approver clicks. No more "sorry, I missed it".

Mobile approval

Approvers tend to be managers, and managers are rarely at a desk. GLPI ships a mobile interface (since 10) and a separate PWA app, both of which show the validation in the same context as the desktop — requester, reason, attachments, prior comments. The approver taps Approve or Refuse and types a short comment on the mobile keyboard.

This is exactly where the email workflow breaks: the approver sees three lines of forwarded text, isn't sure if it's a fresh request or an escalation, and has no context from the prior thread. With in-ticket approval, everything sits in a single pane.

Multi-step approvals

For requests requiring two or more sign-offs (for example line manager → IT manager → CFO when the amount exceeds €5,000), use either sequentially added validations or the Formcreator plugin, which lets you define an approval matrix at the time the form is built. The rule "all approvers must grant before the ticket can close" lives in Setup → General → Approval → Required validations.

For conditional routing (by amount, category, department) and parallel approvals, the native validations can be combined with business rules. For more elaborate processes (CAB review, technical review, backout plan attached, multi-stage gates), it's worth considering the Cascade plugin, which adds a graphical editor for approval chains beyond the native validations.

Audit traceability

Every action on a validation — creation, approval, refusal, change of approver — is written to the object's History with a timestamp and a user. That's the difference from email, where audit depends on:

  • email archive retention policy,
  • the auditor being able to access individual users' Outlook archives,
  • integrity of timestamps (only trustworthy on DKIM-signed messages),
  • completeness of the chain (forwarding chops off part of the history).

For SOX, ISO 27001 or NIS2 audits, there's a real difference between "I'll send you a GLPI export with timestamps" and "let me start asking around to see who still has the emails". For regulated industries, centralised workflow isn't a convenience — it's a compliance requirement.

Migrating from email to a GLPI workflow in practice

  1. Identify the top three approval processes — typically IT equipment purchasing, system access requests, and changes to access rights.
  2. Build a ticket template or a Formcreator form for each with fixed fields (requester, department, amount, justification).
  3. Define an approval matrix — who approves which amount, which category, which system. Store the matrix as business rules, not as tribal knowledge.
  4. Keep notifications narrow — the approver gets a single email with a link into GLPI, not the entire ticket pasted as plain text. The goal is for the approver to open GLPI, not to reply by email.
  5. Close the email path — communicate to teams that requests sent by email won't be approved; they'll be returned with a link to the GLPI form. Without this step, people drift back to the old workflow.

In-ticket approvals aren't just a convenience — they're a shift from "trusting reply-all chains" to "an auditable process with timestamps". For regulated industries and growing teams, that shift is a necessity, not a luxury.

Need help with this topic?

Get in touch