Most service desks automate the wrong things. They chase ticket creation speed or AI auto-responders while the real drag — tickets bouncing between agents, escalations that never fire, reports nobody runs — stays manual. GLPI has six built-in automation mechanisms that cover 90% of what a typical service desk actually needs, and you don't need plugins or custom code to use any of them. Here's what each one does, when to reach for it, and where it sits in the GLPI UI.
1. Business rules — the "every ticket, every field" engine
Business rules are the workhorse. For every ticket that gets created or updated, GLPI runs its business rules in order and applies actions (set assignee, change category, flip priority, add watchers, reject the ticket) based on conditions you define.
Location: Administration → Rules → Business rules for tickets.
Real examples worth setting up on day one:
- Route tickets from
support@vs.infra@to different groups based on the inbound mailbox - Auto-categorize tickets where the title matches keywords ("password reset", "VPN", "printer")
- Escalate priority when the requester is in the VIP group
- Reject tickets with empty title or description back to the requester with a standard message
- Set a default watcher (the requester's manager, pulled from LDAP) on every ticket from a specific entity
Rule ordering matters — GLPI evaluates top-down and can stop on first match. Keep the catch-alls at the bottom.
2. Approval workflows — for requests that need sign-off
Not every ticket should skip straight to an agent. Software requests, new laptop orders, access grants — these need a manager's approval before work starts. GLPI handles this natively through the Approval feature on Request-type tickets.
Location: Ticket → Approvals tab, or automated via the request template.
Set up a request template that automatically adds the requester's manager as approver (or a named approval group). The ticket sits in Approval waiting state, the approver gets a notification, and they click approve/reject from the email or the GLPI UI. Only after approval does the ticket flow to the fulfilment group.
This is a workflow, not just a checkbox — use it for anything that has a cost or a compliance implication.
3. SLA / OLA — deadlines that enforce themselves
If you committed to "critical tickets answered in 1 hour, resolved in 8," GLPI's SLA feature turns that commitment into automatic deadlines, reminders, and breach flags.
Location: Administration → SLA.
Define one SLA per priority level (and one OLA per internal team if you track internal agreements separately). Attach them to ticket categories or business rules. GLPI calculates due dates from ticket creation time, accounting for your defined business hours and holidays, and fires configurable escalations at N minutes before breach and at breach.
The trick: don't define SLAs you don't actually honor. A breached SLA flag that nobody looks at is worse than no SLA, because it trains agents to ignore deadline signals.
4. Ticket templates — shape requests at intake
Tickets without structure become tickets without triage. Templates let you pre-configure required fields, default values, and hidden fields per ticket type or category.
Location: Setup → Dropdowns → Ticket templates.
Useful patterns:
- A "New hire access request" template that mandates start date, department, and manager fields — with those fields driving the approval chain via business rules
- A "Printer issue" template with a required "floor / building" dropdown so technicians know where to go without chasing follow-ups
- A "Password reset" template that's locked-down and auto-assigns to the helpdesk group with priority 3
Combined with business rules, templates make a ticket actionable from the moment it's created — no agent triage round needed.
5. Automatic actions — the scheduled background jobs
The things that happen between ticket events: polling mailboxes, sending queued notifications, closing stale solved tickets, clearing old session data, running LDAP sync. GLPI calls these Automatic Actions.
Location: Setup → Automatic actions.
A production GLPI needs real cron running these — pseudo-cron (on page loads) isn't reliable for background work. See our GLPI cron on Linux guide. Once cron runs reliably, Automatic Actions become invisible infrastructure: mail arrives, notifications go out, housekeeping happens.
Worth reviewing in the Automatic Actions list:
mailgate— poll mailboxes, create tickets from emailsqueuednotification— send notifications GLPI queued earlier (gives you batching and retry)closeticket— close solved tickets after the entity threshold (see our auto-close guide for when this is and isn't a good idea)telemetry— optional, reports anonymized usage to the GLPI project (disable if you don't want it)
6. Recurring tickets — for work that repeats on a schedule
Monthly backup verification, quarterly access reviews, weekly server reboots — anything that recurs on a predictable cadence should be a recurring ticket, not a calendar reminder someone forgets.
Location: Assistance → Recurring tickets.
Create a ticket template, then a recurring ticket entry that generates a new instance on a cron-like schedule. GLPI creates the ticket with the configured category, requester, fulfillment group, and due date automatically. Your team sees it in their queue like any other ticket.
Where to start
Rough order of payoff for a team that hasn't automated anything yet:
- Real cron for Automatic Actions (everything else depends on this)
- Two or three business rules for the highest-volume ticket types
- A couple of ticket templates for your most common request types
- SLAs on priority levels you actually monitor
- Approval workflows for requests that have sign-off requirements
- Recurring tickets for scheduled maintenance work
That's a week of setup at most and catches the majority of what agents complain about. Plugins (FormCreator, Fields, Tasklists) extend this further, but don't reach for them until the built-ins are exhausted — stock GLPI goes further than most teams realize.