In organizations where changes affect production systems, one person’s approval is rarely enough. A server migration needs sign-off from the infrastructure lead, the application owner, and possibly the security team. This is what a Change Advisory Board (CAB) does — and GLPI supports it natively through its approval system.
How approval works in GLPI changes
When a change is created in GLPI, the approval section lets you define who needs to approve it before implementation begins. Approvers can be:
- Specific users — "Jan Novák must approve this"
- Groups — "Anyone from the Security team can approve"
- Multiple levels — "First the team lead, then the department manager"
Each approver gets a notification and can approve or refuse directly from GLPI or from the email notification. The change doesn’t advance to the implementation phase until all required approvals are in.
Designing a practical approval workflow
Low-risk changes: single approval
Routine changes like updating a monitoring threshold or adding a printer — one approver is enough. Set the change category to "Standard" and assign the team lead as the sole approver. Turnaround: hours, not days.
Medium-risk changes: two-level approval
Changes that affect a production service but have a clear rollback plan — like upgrading a GLPI plugin or modifying a workflow rule. First approval: the technical lead who confirms the plan is sound. Second approval: the service owner who accepts the business risk.
High-risk changes: CAB review
Major infrastructure changes, migrations, or anything that could cause downtime. The CAB in GLPI is just a group containing the relevant stakeholders. When a high-risk change is submitted, all group members get notified. GLPI tracks each member’s vote. You can configure whether unanimity is required or majority rules.
Configuring approval chains
GLPI’s approval system supports sequential approval (Level 1 must approve before Level 2 sees it) and parallel approval (all approvers see it simultaneously). The choice depends on your process:
- Sequential — use when earlier approvers may reject and save later approvers’ time
- Parallel — use when speed matters and all approvers should evaluate independently
You can also configure automatic approval rules — if a change of a specific category is submitted by a user with a specific profile, it can auto-approve and skip the manual step entirely. This is how standard/pre-approved changes work.
When the built-in approval is not enough
Sequential chains and parallel groups cover most mid-size deployments. But once your process requires conditional routing — approve via the security architect only if the change is classified high-risk, then escalate to the CAB only if vetoed — GLPI's native approval runs out of configuration options. We built Cascade to handle that shape: multi-stage steps with configurable quorum, conditional branching, and a full audit trail that writes to GLPI's follow-up log. For a broader look at where stock GLPI covers real change management and where it stops, see our assessment of the Change module.
What to avoid
- Too many approvers — if every change needs five sign-offs, people start approving without reading. Keep it to the minimum necessary.
- Approval without context — an approver who receives "Please approve Change #247" with no description will either rubber-stamp or delay. Require the impact assessment and rollback plan fields to be filled before approval is requested.
- No escalation for stale approvals — if an approver doesn’t respond in 48 hours, the change sits in limbo. Set up a notification reminder or delegate authority to a backup approver.
The goal of an approval workflow is not to slow things down — it’s to make sure the right people have verified the plan before it touches production. GLPI makes this a form-and-click process instead of an email chain. If you are standing up change management from scratch, approval workflow configuration is a standard part of a GLPI deployment — not a separate engagement.