Approval workflows in GLPI: multi-step approval processes

The least formal approval process in IT looks like this: someone writes "should we buy that server?" in Slack, a manager replies "ok", and three months later nobody knows who decided what. The most formal looks like email chains with ten recipients and a spreadsheet attached. Between them sits GLPI with built-in validations — approval processes that are auditable without sacrificing speed. This is about wiring them up.

Validations: the built-in approval mechanism

Every Ticket, Change, and Problem object in GLPI has a Validations tab. Through it the requester or technician asks for formal approval from a specific user or group. The approver gets a notification and sees their pending approvals in a single dashboard view.

Three validation states:

• Waiting — requested, pending.
• Granted — approved.
• Refused — declined; comment required.

Every state transition is logged with timestamps. At audit time you have a complete record of who approved what when.

Sequential vs parallel approval

GLPI natively supports both strategies:

• Parallel — multiple validation requests are created at once. Approvers decide independently. Suited to cases where each evaluates a different aspect (manager — budget, tech lead — architecture, security — risk).
• Sequential — the second validation request fires (typically via business rule or manually) only after the first is granted. Suited to formal approval-up-the-chain processes: line manager → director → CFO.

Standard guidance: parallel approvals for speed, sequential for formal hierarchical sign-off.

Conditional routing by cost or impact

For Change Management you typically want different approval paths based on the change's size:

• Standard change (low risk, low cost) — only the tech lead approves. A validation request fires automatically to the lead of the group that owns the change.
• Normal change (medium impact, under €5,000) — tech lead + department manager. Sequential, because the manager wants to know the tech lead has assessed it first.
• Major change (high impact, over €5,000 or touching the production database) — adds the CAB (Change Advisory Board) as a parallel validation.

Implementation: Administration → Rules → Rules for changes defines which validation requests are auto-created when a Change is created. Rule conditions reference Change fields (category, impact, urgency) and custom fields (cost, affected assets).

Timeout escalation when approvers go silent

The most common pain point of any approval process: the approver goes on vacation and the ticket sits. GLPI handles this with SLA-style logic applied to validations:

1. A validation request has an optional Time limit field (e.g. 48 hours).
2. After it expires, the cron task Ticket::cronCheckValidations fires a business rule.
3. The rule can: send a reminder to the approver, escalate to a backup approver, or auto-reject (rarely advisable).

Best practice: one reminder at half the limit, escalation when the limit hits. Escalate to a specific backup, not to a whole group — otherwise you end up with two disagreeing approvers and the change stalls harder.

Audit trail

Every object in GLPI has a Historical tab that records all changes including validations. For audit purposes (ISO 27001, NIS2, financial audit) this is your primary evidence of the approval process. The record contains:

• Who created the request and when.
• Who it was assigned to.
• When and how they responded (Granted / Refused).
• The comment on rejection.

That's the reason formal approval processes belong in GLPI rather than in email — you get a complete audit trail for free, with no extra infrastructure.

Limits of native validations

Built-in validations cover simple approval chains well. Complex scenarios hit ceilings:

• No support for branching by response — there's no "if approver A says yes go to B, if no end here" path.
• No dynamic delegation (a vacation backup must be assigned manually).
• No visual designer — validations are configured via business rules and manual requests.

For richer multi-level workflows with branching, dynamic roles, and a visual map, see our Cascade workflow plugin — built on top of GLPI in a way that preserves the audit trail while enabling more complex processes.

A worked example: buying a new server

1. Requester creates a Change "Buy new Dell PowerEdge", category Hardware → Server, impact High, cost €4,800.
2. Business rule for cost < €5,000 fires two parallel validations: tech lead (vets the spec) + department manager (vets the budget).
3. Tech lead approves within 2 hours.
4. Manager is on vacation. After 24 hours a reminder fires; after 48 hours it escalates to the CFO as backup.
5. CFO approves. The Change moves to Approved state; a business rule auto-creates a ticket "Order Dell PowerEdge" for procurement.
6. The Historical tab shows the exact trail of who did what and when.

Without that record, three years later at audit time nobody can argue who approved the purchase — and that's exactly when formal process pays back the investment.