Approving GLPI requests by email with Approval by mail

Approval by mail lets managers act on GLPI validation requests from an email link. This page covers the configuration decisions, template changes, notification queue checks and the work a partner would scope.

Book a callTalk to us
On this page

How GLPI approval by email works for validation requests

A service desk or change process often stops at a validation step, where a manager must approve or refuse a request before work can continue. When that manager is traveling, on leave or simply slow to log in, the ticket or change sits in a waiting state and the SLA clock keeps running. GLPI's built-in validation requests already record who was asked, what they decided and when. The Approval by mail plugin adds a way for approvers to act from the notification email itself, without opening GLPI first. Teams usually implement it when approvals are a known bottleneck and most approvers work from their mailbox rather than the GLPI interface.

The plugin changes how the decision is taken, not what counts as the decision. Approval by mail sends the validation notification with response options, and the approver's choice is written back to the GLPI validation record. Before rollout, confirm the exact behavior against the plugin's own documentation for your GLPI version, including how the response links are generated, how long they stay valid, whether they can be used more than once, and how they handle a validation that was already answered in the interface. Also confirm how the plugin identifies the approver: a link tied to a specific GLPI user is only as trustworthy as the mailbox that receives it, so mail forwarding and shared inboxes need an explicit decision.

Decisions still need to be recorded and auditable in GLPI. Check that each email approval produces the same validation status, timestamp, approver identity and comment that an in-app approval would, and that the ticket history shows the change. Test refusals and expired links as carefully as approvals. The template and notification settings that generate these emails are covered in the next section, and the queue checks for emails that never arrive are covered in the section after it.

What the Approval by mail plugin does in GLPI

The plugin sends GLPI validation requests to approvers by email and carries their decisions back into GLPI. Each card below names one part of that path and the check to make before you rely on it. Confirm every behavior against the plugin's own documentation for your GLPI version.

Email delivery of validation requests

Approvers receive the validation request by email instead of logging in to GLPI to find it. Confirm which GLPI event triggers the message, whether the approver needs a GLPI account to act, and which mailbox address GLPI uses to send. Send a test message from GLPI's own mail settings first, because a broken sender blocks every approval. Test the outgoing message path before any approver depends on it.

Approve and refuse links

The email carries action links that record an approve or refuse decision without opening the full GLPI interface. Confirm whether each link is single-use, how long it stays valid, and whether the approver must sign in before the decision is accepted. Forwarded emails can reach people who should not decide, so test what happens when a link is opened by someone other than the named approver.

Decision written back to the request

After an approver responds, the decision should appear on the GLPI validation request with the outcome and the time it was made. Confirm that the linked ticket or change moves to the status GLPI's own validation workflow would set, and that a refused request is recorded the same way. Check the written-back status on a test ticket before relying on it for audit trails.

Notification templates carry request content

The subject, body and fields in each message come from GLPI notification templates, so the plugin inherits whatever those templates expose. Review which ticket or change fields appear in the email, since mail leaves GLPI and may be stored by mail providers. Restrict sensitive details such as employee data or contract values to what an approver needs to decide.

GLPI validation remains the system of record

Approval rules, approver assignments, validation history and reporting stay in GLPI's own validation workflow. Treat the GLPI request record as the evidence source for any audit or dispute, and use the email as a delivery and response channel. Confirm with the plugin documentation that every email decision is traceable to a GLPI record, including the approver identity.

What the plugin does not replace

The plugin does not decide who should approve, does not verify that a person at a mailbox is the named approver, and does not secure the mail system itself. Keep approver lists, delegation rules and sign-in requirements in GLPI and your identity provider. Ask the plugin's maintainers which of these responsibilities the plugin leaves to the administrator before rollout.

Which approval setup fits your validation process

This table compares four ways to combine GLPI's in-app validation with email approval from the Approval by mail plugin. Read each row as a trade-off between approver convenience, audit traceability and how much of the validation flow leaves the GLPI interface. The main takeaway is that email approval is easiest to justify for a narrow group of low-risk requests with a tightly controlled template.

OptionWhat changes for approversWhat it means for audit and accessWhen it fits
Approve only inside GLPIApprovers sign in to GLPI and act on validation requests in the interface.Every decision is made under a named GLPI session, which keeps the approval trail in one place.Validators already log in daily, or the request volume and risk call for full in-app control.
Email approval for managers who rarely log inInfrequent approvers act from a link in their mailbox instead of searching for the request in GLPI.Approval depends on the security of the mailbox and the link, so confirm how links are generated, expire and are logged before rollout.A small set of managers who seldom sign in and whose decisions do not need extra review.
Email approval for all validators with a restricted templateAll validators receive a standard message with approve and refuse links and minimal request detail.Access is wider, so the template should expose only what the approver needs and the audit record must still show who decided and when.Large validator groups where in-app approval slows work, provided the template is reviewed by security and records remain complete.
Hybrid: email approval for low-risk requests onlyRoutine, low-value requests can be approved from email, while sensitive requests route to the GLPI interface.Two approval paths need documented criteria, so assessors can see which request types use which channel and why.Organizations that want speed on routine requests and stricter control over changes, purchases or access.

Checking the notification queue when approval emails do not arrive

The approval notification is in the queue, but it never leaves GLPI. This usually means the sending step has not processed the entry, so the problem sits in the scheduler or the mail transport rather than in the plugin's template.

  • Automatic action status: Confirm that the queuednotification automatic action is enabled and shows a recent last run under the automatic actions setup page.
  • Queue entries: Filter the notification queue by recipient and event to confirm the entry exists, and note whether it shows send attempts or an error.
  • Mail transport: Confirm the SMTP host, port, encryption and sender address in the email notification settings, then send a test message from the same screen.
  • Recipient data: Confirm the approver's user record has a valid email address and that notifications are not disabled for their profile or entity.
  • Evidence to capture: The queue entry ID, creation and attempt timestamps, the last automatic action run time and any error text shown in GLPI.

Run the automatic action manually once the transport settings are confirmed, and check that the entry leaves the queue before you change any template.

GLPI approval by email rollout order

This sequence moves email approval from a plugin install to a supervised production cutover, so each validation type is proven with real approvers before managers rely on it. Each step closes with a record the team can check before moving on.

  1. Confirm GLPI version and plugin compatibility

    Record the GLPI version in use and check that the Approval by mail plugin has a release built for that version before anything else changes. Confirm the PHP and database versions against the GLPI prerequisites, and note which other plugins are installed, since GLPI 11 suspends plugins after a new version is detected and they must be reactivated after major updates. The output is a compatibility note signed off by the platform owner, listing the GLPI version, plugin version, PHP and database versions and any plugin that needs reactivation.

  2. Define validation requests for email approval

    Decide which validation requests may be approved from an email link, such as ticket validations or change validations, and which must stay inside the GLPI interface because they need more context or a stronger audit trail. Map each request type to the approver group and the entity it belongs to. The output is a signed-off approver list with one named owner per request type, plus a short list of request types excluded from email approval and the reason for each.

  3. Customize the approval notification templates

    Review the notification templates the plugin sends for approval requests and refusals, then adjust the wording, language and footer so an approver understands what they are approving without opening GLPI. Confirm that the approval and refusal links are generated correctly and that the template makes clear which ticket or change is involved. Keep a copy of the original templates so changes can be reverted. The output is a template test record showing a sample request rendered for each approver language and entity, with links checked.

  4. Configure the mail transport and test sending

    Confirm the outgoing mail configuration in GLPI, including the SMTP host, sender address, authentication and TLS settings, and that the mail address used for approval replies matches what the mail server accepts. Send test messages to internal and external mailboxes and check how each provider handles the links. Record any filtering that quarantines or rewrites the links. The output is a transport test log listing each recipient mailbox, the send time, delivery status and whether the link opened in the expected host.

  5. Run approval and refusal tests with pilot approvers

    Create test validation requests and ask a small group of pilot approvers to approve some and refuse others, using only the email links. Check that each action updates the validation status in GLPI, that the requester receives the expected follow-up notification, and that the ticket or change history records who acted and when. Repeat the test for each request type on the approved list and include a refusal with a comment. The output is a test log where every request type has one approval and one refusal recorded with the matching GLPI history entry.

  6. Check the notification queue when mail does not arrive

    Before cutover, learn how to diagnose a missing approval email. Check the notification queue in GLPI for the pending message, confirm that the related automatic action is running, and review the mail server logs for the same recipient and time. Repeat this check with a deliberately misaddressed test so the team knows what a failed send looks like. The output is a queue check log with the queue entry, its status, the automatic action run time and the mail server result for the test failure, stored with the runbook.

  7. Cut over with a documented rollback plan

    Enable email approval for the signed-off request types only, announce the change to approvers and requesters, and watch the first live requests closely. Keep the previous approval method available and document the exact steps to disable the plugin or revert the templates if approvals stop arriving. Agree who decides on a rollback and how approvers are told to use the GLPI interface in the meantime. The output is a cutover record with the enabled request types, the rollback steps and the named decision owner, reviewed after the first live approvals are complete.

What drives approval by email effort and cost

This table breaks the approval by email work into its cost components, showing who is paid for each, what pushes effort up, and what to keep down. Use it to compare a written scope from a partner against the work your own team would carry, and to see which items recur after go-live.

Cost driverWhat raises effortWhat reduces effort and what to ask for in a quote
Plugin installation and version validationRunning the plugin on a GLPI version it was not tested against, several GLPI instances or entities with different settings, and plugin state changes after a GLPI update that must be reactivated.Confirm the plugin release matches your GLPI version. Ask the quote to name the GLPI version tested, the number of instances and whether staging is included.
Template design per request typeMany validation types (hardware, software, access, purchase), each needing its own wording, approver logic and language variants for different user groups.Limit the first release to the request types that truly need email approval. Ask for the number of templates in scope and who reviews the wording.
Mail transport and deliverabilityApproval links depend on outbound SMTP settings, sender identity, SPF, DKIM and DMARC records, and whether the mail gateway rewrites or scans links before approvers click them.Ask who owns the mail domain and gateway changes. Confirm a test send path through the same gateway approvers use, and whether the quote covers coordination with your mail team.
Approver access and identity decisionsApprovers who are external, on mobile devices, or who sign in through different identity sources; decisions on whether an emailed link alone is accepted or a confirmation step is required.Agree the approval security model in writing before build. Ask the quote to state how approver identity is checked and who signs off the decision.
Testing across validation typesEach validation outcome (accept, refuse, expired or already-answered requests) and each approver path needs a repeatable test, including cases where mail is delayed or lost.Ask for a written test matrix with the validation types, outcomes and environments covered, plus the acceptance criteria the client signs.
Notification queue checksDiagnosing emails that do not arrive means reviewing the notification queue, mail server logs and the GLPI scheduled tasks that send queued messages.Ask whether the quote includes a runbook for queue checks and whether your team receives access to the logs needed to follow it.
Upgrade retestingEach GLPI minor or major update may change notification behavior, and plugin reactivation after updates adds steps to the release checklist.Ask for the retest scope per GLPI upgrade and whether it is one-time or part of an ongoing support retainer.

How approval by email connects to the rest of GLPI

Approval by mail sits on top of several GLPI subsystems that each fail in their own way. Mail transport, sign-in, queued notifications, and the requests that trigger them all have to work together before a manager can act from an inbox.

Mail transport and receivers

Outgoing approval emails leave through the SMTP settings in GLPI, while replies and link clicks depend on how your mailboxes are read. If you also use mail receivers for email-to-ticket, confirm which mailbox GLPI uses for notifications and that no receiver consumes messages meant for approvers. Ask your mail team whether the sending domain has SPF, DKIM and DMARC records that match the GLPI sender address, since unauthenticated mail is the most common reason approval emails land in spam.

Sign-in order for approvers

GLPI tries authentication sources in a fixed order: the internal database, then LDAP directories, then IMAP mail servers, then other external methods such as REMOTE_USER. An approver who exists only in the directory may be matched later than expected, or may sign in with a local account that was never meant for them. Confirm which source each manager's account resolves through, and whether the approval link requires a session that already exists or prompts for sign-in.

Notification queue and automatic actions

Approval emails are not sent at the moment the request is saved. They enter the notification queue and are dispatched by a scheduled automatic action, so a stopped or slow cron job looks like a missing email. When approvals do not arrive, check the queue for pending and failed entries before changing templates. Confirm that the automatic actions run on the schedule your operations team monitors, and record who receives alerts when the queue backs up.

Validation requests and business rules

Approval requests are created by validation workflows on tickets or changes, and business rules can set which requests are generated, who the validator is, and when the request is raised. A rule that reassigns the ticket or changes its category can also change who receives the approval. Test each rule with a sample ticket that matches the real routing conditions, and confirm that the validator group contains people who still hold the approver role.

Upgrade path to GLPI 11 and 12

Plugins are suspended in GLPI 11 when a new version is detected and must be reactivated after major updates, so an approval plugin can stop sending links until someone turns it back on. Confirm the Approval by mail version is compatible with your target GLPI release before you schedule the upgrade, and back up the database, files and the config directory, including glpi.key and glpicrypt.key, first. Add approval emails to your post-upgrade test list.

Questions teams ask before approving GLPI requests by email

Can our own team set up approval by email in GLPI?

In many organizations, an internal GLPI administrator can install and configure the Approval by mail plugin, provided they can reach the GLPI server, control its mail settings and test approvals end to end. The work is mostly configuration and testing, but it depends on your GLPI version, your mail path and how many approval flows you need. Before you decide, confirm with the plugin's own documentation which GLPI versions it supports, and have someone who owns your mail server review the sending path. If your team has not run a GLPI upgrade or changed notification settings before, a scoped engagement with a partner can cover the gaps. DeployOpen plans and implements these changes in your infrastructure under a written scope.

What drives the cost of approval by email in GLPI?

Cost depends on the number of approval flows, how many templates you must change, how your mail infrastructure is set up and how much testing your change process requires. Other drivers are whether approvals must be traceable for audit, whether you need a staging copy of GLPI for testing, and how often the plugin must be retested after GLPI updates. Some costs are one-time, such as design, configuration and testing. Others recur, such as plugin maintenance and retesting at each upgrade. When you ask for a quote, request a line for each of these items, the staging work, the template changes and the upgrade retest, so you can compare it with your own effort. DeployOpen does not publish a price list and quotes follow from the written scope.

How long does an approval by email rollout take?

The pace is usually set by decisions and testing, not by the plugin installation itself. The longest steps are typically agreeing which requests need email approval, getting change owners to review the approval and refusal wording, and proving that mail is delivered reliably through your own mail services. A staging environment that mirrors production makes this faster. The GLPI version you run also matters, because a planned upgrade may need to happen first. Ask for a timeline that lists each approval flow, the test cycles and any dependency on a mail or GLPI upgrade, and confirm the dates against your own change calendar. DeployOpen agrees timelines in writing before work starts.

What does the work need from our team?

The work needs a GLPI administrator, a mail administrator and a business owner for each approval type. The GLPI administrator installs and configures the plugin and controls the templates. The mail administrator confirms the sending path, sender identity and any filtering that could hold approval messages. The business owner, often a service or change manager, reviews the wording and confirms who can approve each request. Someone with access to the GLPI server must also keep a current backup of the database, files and the glpi.key and glpicrypt.key files before any change. Ask for the time commitment of each role in your quote, so your team can plan its availability.

Do approvers need a GLPI account to approve requests by email?

This depends on how the plugin handles the link in each email, and you should confirm it in the plugin's documentation before you design the process. If the link requires a GLPI session, each approver needs an account with a profile that allows the validation, and you must test that path with that account. If the link works without a session, the approval identity relies on the link and the message delivery, which changes your audit and risk position. Whichever model applies, write down which people may approve each request type, test the flow with an approver who has no GLPI login and keep the list of approvers current when people change roles.

How is security handled for approval links sent in email?

An approval link in an email can act as a decision, so its design matters as much as its appearance. Confirm whether the plugin uses single-use or expiring tokens, whether it binds the decision to the named approver, and whether it records who clicked and when. Also confirm that GLPI is served over HTTPS and that the link host is the one your users expect. Email can be forwarded, stored in mail archives and read on shared devices, so approvals for high-impact requests may need a confirmation step inside GLPI. Ask your security team to review the link design and the logging before rollout, and test refused and expired links as carefully as approved ones.

What happens to approval email during a GLPI upgrade?

During an upgrade, the plugin may be suspended until you reactivate it. Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates, according to the GLPI update documentation. Before any upgrade, back up the database, the files and the config directory, including glpi.key and glpicrypt.key, and then run php bin/console db:update as the procedure describes. After the upgrade, test an approval and a refusal end to end, check that the plugin is active and confirm that your templates still hold your wording. Keep this retest in your upgrade plan and in your quote. The GLPI update documentation is the starting point for the steps.

Why do approval emails sometimes not arrive?

Missing approval emails usually come from the sending path rather than the plugin logic, so check the chain in order. First, confirm the notification is queued in GLPI and that the automatic actions that send queued notifications are running. Then check the outgoing mail configuration, the sender address, the mail server's logs and any spam or quarantine rules that might hold messages with links. Also check the recipient's account settings in GLPI, because a missing or wrong email address stops delivery. Record which step failed, so you can fix the cause rather than resend messages by hand. If the problem appears only after an upgrade, check the plugin's active status first.

How DeployOpen scopes and delivers GLPI approval by email

DeployOpen treats email approval as a workflow that touches identity, mail delivery, GLPI notifications and the people who answer approval requests. We start from the validation process your managers already follow, then plan the plugin, templates and mail path inside infrastructure you control. The result is a written scope and a tested handover rather than a generic plugin install.

How we scope

  • Map which GLPI validation requests managers must answer by email and which must stay inside the web interface
  • Confirm the GLPI version and the Approval by mail plugin compatibility before any build work starts
  • Agree in writing the mail server, sending address and reply handling that the approval links depend on
  • Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins

How we build

  • Install and configure the Approval by mail plugin on a test instance that mirrors your production GLPI
  • Adjust notification templates so approval emails show the ticket, requester and decision options clearly
  • Test approve and refuse links with managers, requesters and shared mailboxes across each validation path
  • Check the notification queue and mail transport logs during tests to confirm emails leave and arrive

How we hand over

  • Document the approval workflow, template variables and the mail settings the plugin depends on
  • Provide a checklist for the notification queue and mail delivery checks used when emails do not arrive
  • Walk your administrators through reactivating plugins after GLPI updates, since plugins are suspended on new versions
  • Deliver the configuration backups and records your team needs to repeat the setup or audit it later

How we support

  • Plan plugin reviews and re-tests into each GLPI update, including the required database backup before updates
  • Ongoing support, upgrades and continuous testing are available as retainers after handover
  • Confirm with your team who owns mailbox changes, DNS records and mail relay settings after go-live
  • Ask for a quote that separates one-time build work from any recurring support you choose to add

Sources and further reading

Related

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.
Book a callhello@deployopen.com