Cross-department approval chains in GLPI: validators, voting, and routing

Cross-department approval chains in GLPI: validators, voting, and routing

A laptop request for €1,200 arrives. The line manager needs to nod. Then the cost-center owner. Then the head of finance. Then IT can actually buy and deploy. If any one of those four steps gets buried in an inbox, the laptop arrives a month later than promised. Cross-department approval is the workflow that most often runs on email, breaks most often, and has the loudest political consequences when it does. GLPI's Validations feature handles this without third-party plugins — once you stop trying to use Tasks for what Validations are for.

Validations vs. tasks: a clean distinction

A Task in GLPI represents work to be done. A Validation represents permission to proceed. They look similar in the UI but mean different things. The validator doesn't do something — they answer yes or no. Putting an approval in a Task means it appears in the technician's queue as work-to-do, which it isn't. Putting work in a Validation means it sits there waiting for an answer that doesn't apply.

Open any ticket. The Approvals tab is the Validations panel: request a validation, choose a validator (a single user or a group), add a short justification message. The validator gets notified, opens the ticket, clicks Approve or Refuse with optional comments. The ticket can be configured to block on outstanding validations — agents can't close it until every validation is decided.

Sequential approval: the staircase

The simplest pattern: each approver decides in turn. Manager approves → finance approves → IT proceeds. In GLPI, this is configured via a business rule that creates the next Validation when the previous one is approved. The agent submits the ticket; rule fires "Request manager approval". When manager approves, rule fires "Request finance approval". And so on.

The advantage of sequential is auditability — you can read the chain top-to-bottom and see who said yes in what order. The disadvantage is speed — each step waits for the previous one. If your finance head is on vacation, the chain stalls.

Parallel approval: the voting committee

The alternative: request all validations at once and require either all approvals or a majority. GLPI supports both modes. Open Setup > General > Assistance > Validation: choose between All validators must approve and Approval by a single validator. The latter is useful when you have a committee where "any one of these three people can authorize" — useful for emergency requests where you don't want to wait for a specific manager.

Parallel is faster but harder to audit (who looked first? who waited for the others?). Use for low-stakes, time-sensitive approvals — emergency hardware swaps, urgent access grants. Sequential for high-stakes — budget over a threshold, security-sensitive access, contract signing.

Threshold-based routing

Not every request needs the full chain. A €50 mouse purchase shouldn't trigger CFO sign-off. A €5,000 laptop should. Use business rules on the ticket category and the cost field: if cost < €500, no approval needed; if €500-2000, manager only; if > €2000, manager + finance + CFO. The rule fires at ticket creation and creates the appropriate validations.

This is where the form intake matters: if the cost field is missing or wrong, the rule routes wrong. Make cost mandatory on the relevant ticket templates. The cost of getting it wrong (a CFO copy-and-paste on a mouse request) outweighs the cost of one extra mandatory field.

Delegation and escalation when approvers are absent

GLPI's validation system supports a delegated approver per user — set at Administration > Users > (user) > Substitute. If the manager is OOO, validations route to the deputy automatically. Configure this once per manager during onboarding; the chain continues to work when people travel.

For pure escalation when even the deputy doesn't respond, add a business rule: if a validation is still pending after 5 business days, escalate to the next-level approver. The validation request changes assignee; the original approver sees in their queue that they timed out, which is its own behavioral signal next time.

The audit value

For SOX, ISO 27001 Annex A.9 (access control), and any internal control framework, the question "who approved what spend and when" must have a paper trail. GLPI's validation history — visible in the ticket's Historical tab — answers it: timestamp, validator name, decision, comment. Export annually as part of audit prep. The same workflow that speeds up approvals also produces the evidence that auditors will ask for, without any separate logging system.

Need help with this topic?

Get in touch