A GLPI without configured notifications is a black box — things happen, but nobody knows about them until someone opens the UI. With notifications it becomes a communication hub: the technician gets an email when a P1 ticket lands on them, the requester knows when their request moves, the manager gets a daily digest of open escalations. Configuration has three layers: templates, events, and conditions.
Templates: what gets sent
Under Setup → Notifications → Notification templates you define email templates for various objects (Ticket, Change, Project, Asset…). Each template has:
- Subject — email subject line with placeholders.
- Text body — plain-text version (for clients that don't render HTML).
- HTML body — rich version with formatting.
Placeholders use double-hash syntax: ##ticket.title##, ##ticket.id##, ##ticket.url##, ##ticket.requester.name##, ##ticket.assigntechnician##, ##ticket.priority##. Available placeholders depend on the object type — the full list is in the documentation, or in the UI under each template's Tags tab.
An example template for "new ticket assigned to technician":
Subject: [GLPI ###ticket.id##] ##ticket.title##
A new ticket has been assigned to you:
Ticket #: ##ticket.id##
Title: ##ticket.title##
Priority: ##ticket.priority##
Requester: ##ticket.requester.name##
SLA TTR: ##ticket.sla.ttr##
Link: ##ticket.url##
Description:
##ticket.description##The ##ticket.url## placeholder expands to a direct URL into GLPI. That's critical — without a clickable link the technician either wastes time hunting, or ignores the email altogether.
Events: when it gets sent
Under Setup → Notifications → Notifications you wire templates to events. An event is a system action like:
- Ticket → New ticket — a new ticket is created.
- Ticket → Update ticket — any change.
- Ticket → New followup — a comment is added.
- Ticket → Add task — a task is added to the ticket.
- Ticket → Add solution / Solve / Closure — resolved or closed.
- Ticket → Validation request / Validation answer — approval flow.
- Asset, Project, Change, Problem — analogous events for other objects.
For each event you set:
- The template from the previous step.
- Recipients — who gets the notification. Options: Author, Assigned technician, Watcher group, Recipient (any user listed in the template), Manager of requester (LDAP), or a fixed user/group.
- Mode — email, or plugin-driven channels (Slack, Teams).
Conditional rules: when it ISN'T sent
An unfiltered notification setup is often the source of inbox noise — every ticket change generates an email, the technician becomes immune within a week and starts ignoring even critical ones. Under Administration → Rules → Rules for notifications you define the conditions that decide whether the notification fires:
- Send only for P1/P2 tickets — IF priority < 4 → THEN deny notification. The manager then only gets emails for critical and high-priority cases.
- Send only for own entity — IF entity != current_user.entity → deny. Multi-tenant scenarios where different clients must not see each other's tickets.
- Mute outside business hours — IF time NOT IN (08:00 – 18:00) AND priority < 5 → defer to next morning. For P3 and P4 nobody needs a 3am ping.
- Suppress notifications on own actions — when a technician comments on their own ticket they don't need to email themselves. Set Setup → General → Notifications → Notify the actor of an action to No.
Test before going live
Before turning a notification on for real comms, test it via Setup → Notifications → Notifications → open the notification → Test button. GLPI renders the template with a sample object and sends the email to a configured recipient. That surfaces missing placeholders, broken HTML, and characters that shouldn't be there. Without testing it's common to discover, post-deployment, that the manager is receiving emails with ##ticket.priority## instead of the real value — the placeholder name was different in their GLPI version.
Working tip: per-user notification preferences
Each user has a Personalization → Notifications tab in their profile, where they can manually mute specific categories. This is best leveraged by senior technicians who also receive notifications from monitoring tools — it lets them turn down their own noise.
Notifications in GLPI aren't "set and forget". They're an iterative system — the first two weeks after rollout reveal who gets too much, who gets too little, which templates are missing. A weekly review with the team is the fastest way to tune notifications. For Slack, Teams, and other channel integrations see the notification integrations guide.