How GLPI routes high-impact changes to a Change Advisory Board
Routing rules in GLPI decide which changes reach a Change Advisory Board (CAB) group and which ones go straight to a technical queue. In a GLPI deployment, a CAB routing rule is an automated assignment that reads a change's urgency and impact, plus other criteria you define, and then sets the group, the approval step or the validation request without a dispatcher picking it up by hand. Without that automation, high-risk changes can sit in the wrong queue, reach production without a second review, or wait for someone to notice they belong with the CAB.
GLPI's change module and its validation features are the building blocks. Changes can carry a validation request sent to named approvers or groups, and that validation is recorded on the change itself, so the approval trail stays with the record. Automated routing becomes worth the effort when change volume is high enough that manual triage misses items, when several teams submit changes that need different review paths, or when an audit expects proof that high-impact changes were reviewed before implementation. Confirm the exact rule criteria available in your GLPI version (for example, whether you can match on change type, category, planned dates or a specific requester group) by testing them in a non-production instance, because the business rules engine and its available fields change between releases. The GLPI project site is the starting point for the documentation for the version you run.
Plan the routing before you build any rules. Decide which combinations of urgency and impact must reach the CAB, which infrastructure problems should go to level 3 teams instead, and which validation stage each path needs (for example, a technical review before a CAB decision). Then confirm with your change manager how emergency changes bypass or shorten the normal path, and who signs off on that exception. Test each rule with sample changes that cover every branch, and check that rule order does not send a change to the wrong group before a later rule fires. Keep a written record of the test cases so the routing can be re-verified after each GLPI upgrade.
Which routing approach fits your change process
One CAB group receives every high-risk change through a single business rule. This is the simplest model to explain to auditors and to keep consistent, but every approver sees every change, which can slow review in entities with little overlap.
- Who maintains the rules: A small set of GLPI administrators owns one rule set and the CAB membership group. Membership changes should follow the same review as other configuration changes.
- Missing urgency or impact: Conditions that test urgency and impact can fail quietly when a field is empty, so the change never reaches the board. Add a fallback rule or a mandatory-field check on the change template.
- Load across the organization: One queue grows with every entity. Decide who triages non-urgent approvals so the board sees only changes that need its judgment.
- Audit trail: The change history and validation records show which group approved and when. Confirm with your GLPI version how rule actions are logged before you rely on that log as evidence.
Before go-live, submit a test change with blank urgency and impact and confirm that it reaches the group you expect.
Each entity or service has its own CAB group, and rules key on entity or category to pick the right group. Reviewers see only the changes they can judge, but the number of rules grows and overlaps become a risk.
- Who maintains the rules: Entity or service owners maintain their own rules, or a central team maintains them under delegation. Decide in advance which rules the central team keeps control of.
- Missing entity or category: A change without these values may match no group at all. Set a default catch-all rule that routes to a central group so nothing waits unassigned.
- Overlapping matches: A change that touches two services can match two rules and create two validation requests. Define rule order and test multi-entity changes explicitly.
- Audit trail: Each group's decisions appear in the change record, but the full routing logic is spread across several rule sets. Prepare a single exported view of the rules and their order for auditors.
For illustration, a change touching two services with one blank category should show which group received it and why, and that result should match your documented routing design.
The change manager reviews each change and adds the CAB validation request by hand. Judgment applies case by case, but outcomes depend on the individual and on who is available at the time.
- Who maintains the process: The change manager owns the procedure, the CAB roster and the templates. There is no rule set to maintain, so the process depends on written guidance and training.
- Missing urgency or impact: The manager can still forward an incomplete change. Make urgency and impact mandatory on the change template so the decision is made on recorded data.
- Availability and speed: An urgent change waits on one person. Name a backup manager and define an out-of-hours path for emergency changes.
- Audit trail: Validation requests and comments show who decided and when. The reason a change was or was not sent to the board should be written into the change record, and the procedure should require that note.
Confirm with your change manager how often manual decisions are reviewed against the written criteria, since consistency is the main risk in this model.
Configuration options for CAB routing and approval
This table compares the configuration choices that decide how a high-urgency, high-impact change reaches a Change Advisory Board and how infrastructure problems reach level 3 teams. Read each row for when the option fits and what it cannot override, then confirm the behavior against your GLPI version before you build the rules.
| Option | When it fits | What it cannot override |
|---|---|---|
| Urgency and impact criteria | Use when the CAB should see only changes above a set risk threshold, so routine standard changes skip the board. | Criteria match the values on the change at evaluation time, so manually edited urgency or impact can still bypass them if users can change those fields. |
| Group assignment to the CAB | Use when a single named group must receive validation requests for every matching change across entities. | Assignment rules set the group on the change, but they do not add members to the group or decide who approves. |
| Validation request steps per stage | Use when a change must pass technical review before business approval, with a different approver group at each stage. | Stage order and approver groups define the path, but a requester or a user with rights can still send a change to a stage that the process did not intend. |
| Rule order | Use when several routing rules could match one change and the first match should win, such as an emergency rule above a general one. | Rule order decides only among rules that match, so a later rule cannot reverse a value a higher rule already set unless the rule is written to do so. |
| Level 3 escalation for infrastructure problems | Use when a problem ticket about core infrastructure should reach the specialist team directly instead of waiting in level 1 or level 2 queues. | Escalation routes the ticket to a group, but it does not replace the SLA or OLA clock that still runs on the ticket. |
| Pending status and approval timing | Use when the change should wait for a CAB decision without the service desk clock running against the customer target. | Pending status pauses the clock only where your SLA and OLA calendars are set to honor it, so confirm calendar and status behavior in your version. |
| Manual overrides by technicians | Use when an experienced change manager must reroute a change in an unusual case and record the reason. | Overrides are only as controlled as your profile rights, so restrict who can edit urgency, impact and assigned groups. |
Setting up CAB routing rules step by step
This sequence turns a change advisory board policy into GLPI configuration: a defined CAB group, criteria for which changes reach it, validation steps for each stage, and routing rules that send infrastructure problems to level 3 teams. Each step ends with a check so the build can be verified before go-live.
Define the CAB group and its membership
Create a dedicated group in GLPI for the change advisory board and add the named approvers, along with any alternates who cover absences. Agree with the change manager who owns membership changes and how often the list is reviewed. The step is complete when the group exists, every member can sign in, and a test validation request can be assigned to the group rather than to a single person.
Set urgency and impact criteria for CAB review
Write down which combinations of urgency and impact must reach the CAB, such as high urgency with high impact, and document the rule in the change process. Check how your GLPI priority matrix computes priority from urgency and impact before relying on it, because routing conditions depend on the same fields. The output is a written criteria table that the routing rules will implement exactly, with no interpretation left to the person creating the change.
Configure validation steps for each stage
Define the validation stages for a change, such as technical review, business review and CAB approval, and decide which validators or groups act at each stage. Confirm in your GLPI version how change validation requests are created and whether a stage can require more than one approver. The step is complete when a sample change moves through each stage in a test entity and every stage shows the expected validator.
Create routing rules in the business rules engine
In the business rules engine for changes, create rules that match the criteria from the earlier step and assign the CAB group or add the validation request for it. Set the rule order so that the CAB rule runs after rules that set urgency, impact and category, because later rules can overwrite earlier values. Keep the number of rules small and name each one by its purpose. The check is a rule list that a reviewer can read top to bottom and map to the written criteria.
Add level 3 routing for infrastructure problems
Create a separate rule for problems in infrastructure categories that assigns them to the level 3 group and, where needed, links the affected change or incident. Confirm which category and asset conditions identify infrastructure work in your catalog, and make sure the rule does not also trigger CAB review unless your policy says it should. The output is a rule that routes only the intended problems, verified by a test problem in each affected category.
Test with sample changes
Create a set of sample changes covering each combination of urgency and impact, plus one infrastructure problem, and run them through the rules in a non-production entity. Record for each sample which rules fired, which group received the validation request and what priority was set. Investigate any sample that routes differently from the written criteria, and adjust rule order or conditions before repeating the tests.
Check validation requests and notifications
For each passing sample, confirm that the validation requests appear for the correct approvers, that approvers receive notifications and that the change history shows each approval or refusal. Check the notification queue and the mail delivery path if messages do not arrive, since a rule that routes correctly is not useful when approvers never see the request. The step is complete when every approver in the test has received and acted on at least one request, and the results are documented for the change manager to sign off.
Security and access risks in change approval routing
Routing rules decide who sees a change and who can approve it, so an error in those rules can turn the Change Advisory Board into a formality. The cards below cover the common failure points, from membership and profile rights to the audit trail left behind when rules change.
Overly broad CAB membership
A CAB group that collects every senior engineer or every team lead quickly stops reviewing anything. Each member who can validate a change adds a path where a high-impact request is approved without real scrutiny. Review the group membership against the people who must assess risk, and confirm who may add or remove members. Keep the group small enough that each approver can name the systems they are accountable for.
Rules that bypass validation
A business rule that assigns a change to a group, sets its status or fills in a validation field can also skip the validation step if its conditions are too loose. Check every rule that touches status, validation or the urgency and impact fields, and test it with a high-impact sample change. Confirm that no rule can mark a high-impact change as approved without a recorded validation request.
Approval rights tied to the wrong profiles
Validation rights in GLPI come from the profile assigned to a user within an entity, so a user who holds a broader profile than intended can approve changes they should only request. Review which profiles grant change validation and check that they are assigned per entity, not globally by accident. Verify with a test account for each role before go-live.
Admin rights that edit routing
Anyone with rights to edit business rules, groups or profiles can change where approvals go. Limit rule editing to a named set of administrators and keep it separate from the people who approve changes. Ask who can edit rules in your instance today, and whether that list matches your change policy.
Step-up checks for sensitive admin actions
GLPI 12.0.0 added step-up authentication for certain administrative actions, which can add a re-authentication prompt before sensitive changes. Confirm which actions in your version require it, and whether it covers rule and profile edits. Treat any gap as a finding to close with your own profile restrictions, not as a reason to skip the check.
Audit gaps when rules change
Routing rules are often edited under time pressure during a change freeze, and the edit may leave no clear record of who changed what and why. Keep a written change record for every rule edit, export the rule set on a schedule, and compare exports to spot unexpected changes. Confirm which rule and profile edits your GLPI version logs, and where those logs are retained.
Questions teams ask before configuring CAB routing
Who does the work of setting up CAB routing rules in GLPI?
Your internal GLPI administrator can configure the rules, groups and validation steps if they know GLPI's change and business rules well, and DeployOpen can do the design and build under a fixed scope if they do not. The work splits into three parts: deciding how changes should flow (the process design, which is mostly your decision), building the rules and groups in GLPI, and testing them against realistic change records. Most of the effort sits in the first part, so the decisions your CAB has already made, or has not made yet, shape the rest. Ask any partner to state in writing which of these three parts they own and which parts your team must staff.
What makes the cost of CAB routing go up or down?
The main drivers are the number of approval stages, the number of CAB and level 3 groups involved, how many GLPI entities need different routing, and whether your change process is already documented. Each added stage needs its own validation logic, notification behavior and test cases. Multiple entities multiply the rules, because each entity may route changes to different groups. Existing documentation, such as a CAB charter and written urgency and impact definitions, shortens the design phase considerably. Ask for a quote that lists stages, groups, entities and the documents you will supply, since those items determine the scope.
How long does testing take for CAB routing rules?
Testing length depends on the process you are routing, not on the GLPI configuration alone. A single emergency path with one approval stage is simpler to verify than a standard, normal and emergency model that spans several entities and teams. Testing should cover each urgency and impact combination that reaches the CAB, each validation stage, rejection and resubmission paths, and the handoff of infrastructure problems to level 3 teams. Ask your partner to base the test plan on your own change scenarios and to agree on the acceptance criteria in writing before the build starts.
What must our team provide before configuration starts?
Prepare a CAB charter that names members, meeting cadence, quorum and decision authority, plus written urgency and impact definitions that match the priority matrix you use. Also provide the list of groups that should receive routed changes, the level 3 teams that handle infrastructure problems, the approval stages you expect, and a set of example changes from the last year that show how they were handled. Without these inputs, the build will encode assumptions that the CAB may later reject. Confirm with your change manager who owns sign-off on each input.
Can an internal admin set up CAB routing alone?
An internal admin can set up CAB routing alone if they have GLPI administration experience, access to a non-production instance, and an agreed process owner who can make decisions about approval stages and urgency definitions. The difficult part is rarely the GLPI screens. It is resolving disagreements between change management, operations and security about who approves what, and that work often stalls without an outside facilitator. Many teams therefore keep the admin in the build and bring in a partner for design workshops or test review. Decide which of these roles you can fill before deciding who does the work.
Does routing a change to the CAB ensure the change is approved?
No. Routing rules decide which group receives a change and which validation steps it passes through, but they do not decide whether the change is safe or whether the CAB will approve it. Approval depends on the CAB's decision, the evidence in the change record and your governance policy. Routing rules reduce manual triage and help the right people see the right changes in time. Any partner should describe the configuration as routing and validation logic within your process, not as a control that guarantees a particular outcome.
What happens to CAB routing when the change process changes?
Each change to urgency definitions, approval stages, group membership or CAB cadence needs a rule update, a retest and a record of who approved the change to the configuration. Plan for this from the start by keeping the rules documented alongside the process charter and by assigning an owner for GLPI configuration changes. If you upgrade GLPI, check how the change and business rule behavior is affected before you upgrade, and confirm the upgrade steps with your vendor and in your own test environment. Ask any partner how they handle post-build changes and whether that work sits inside a fixed scope or a support arrangement.
What to confirm in your GLPI environment
CAB routing depends on a handful of GLPI behaviors that differ by version, configuration and installed plugins. The cards below list what to verify in your own instance before you copy any rule design into production, and why each check changes the outcome.
GLPI version and change behavior
Confirm which GLPI release you run, then check the change and validation behavior against the documentation for that exact version. GLPI 11.0 and 12.0 are separate lines with different defaults, so a routing design tested on one may not behave the same on the other. Record the version in your change standard so reviewers know which rule set applies.
Rule ordering and override limits
Business rules run in a set order, and some fields can be overwritten by later rules or by a technician's manual edit. Test whether a high-urgency, high-impact change lands in the CAB group after every other rule has run. Write down which fields the routing rule may set and which it must never change, such as the approval requirement itself.
Validation steps per stage
Check that each validation stage in your change workflow maps to a validator you actually intend to notify, and that the approval is not skipped when the change moves between states. Confirm whether a validator can approve on behalf of a group, and whether a rejected validation returns the change to its owner. Walk one emergency change and one standard change through the full path.
Notification delivery
Approval routing fails quietly if notifications do not reach the validators. Confirm the notification templates, the recipient rules and the mail configuration, and check the notification queue after a test change. Ask whether your mail relay accepts messages from GLPI and whether approvers receive the links they need.
Plugin dependencies
Identify every plugin that touches changes, validations, forms or groups, and confirm it is compatible with your GLPI version. After a new version is detected, GLPI 11.0 suspends plugins until they are reactivated, so a routing design that depends on a plugin can stop working after an update. Keep a dated list of plugin versions in your change record.
Email approval requirements
Decide whether approvers should act from email links. If they should, confirm whether your GLPI build provides that capability natively or whether it needs the Approval by mail plugin, and test the plugin's template changes on your version. Without this check, a CAB decision may depend on someone logging into the web interface during an urgent window.
Level 3 team routing
Confirm the groups, entities and categories that send infrastructure problems to level 3 teams, and check that the routing does not change the customer-facing SLA. Verify which group receives the ticket when a level 1 agent escalates, and who owns it when that group is empty or inactive.
How the change process shapes the build
The routing rules in this topic are only as good as the change policy behind them, so the first decision is not technical. Before any rule is written, the organization needs a signed-off change process that defines which changes are standard, normal or emergency, what counts as high urgency and high impact, who may approve a change at each stage, and who owns the CAB's decisions when members disagree or are unavailable. Those answers determine the group names, the validation steps and the conditions the business rules test. DeployOpen starts from that written process, not from GLPI's defaults, because a rule that routes to the wrong group is harder to unwind once tickets are already flowing.
Confirm three things with the change manager before design starts: the named owner of CAB decisions and their delegate, the criteria that trigger CAB review (urgency and impact values, category, or both), and whether emergency changes are approved after the fact. Those answers map onto specific GLPI objects, including the groups and approval requests that the rules assign, the priority matrix that computes priority from urgency and impact, and the validation steps. Ask the client to write them down with example changes so the build can be tested against real cases rather than assumptions.
The change process also sets the clock. A CAB approval step that waits for a meeting will push a change past its target, so the SLA and OLA targets, and any escalation levels that reassign or notify when they are missed, must be designed together with the approval flow. Ticket SLAs describe what the customer is promised, while the OLA for the CAB group describes how long approval may take internally, and the two should not be configured in isolation. Review the combined timings with the change manager before go-live so that escalation does not fire on a change that is simply waiting for its scheduled review.
How DeployOpen works on this
DeployOpen plans, implements, customizes, documents and supports self-hosted GLPI inside your own infrastructure. For CAB routing, we start from your change policy and the groups that really approve work, then build and test the routing in a GLPI instance you control.
How we scope
- Map your change types, urgency and impact levels to the priority matrix before writing any routing rule
- Agree which groups form the CAB, which validation stages they own and who covers emergency changes
- Record the level 3 teams that receive infrastructure problems and the routing conditions that send them there
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
How we build
- Configure business rules in a staging GLPI copy, with rule order and criteria documented for each branch
- Test high-urgency, high-impact changes, standard changes and infrastructure problems with representative sample records
- Confirm approval steps per validation stage, including what happens when an approver is absent or refuses
- Check that rules cannot overwrite manual values where your change process requires human judgment
How we hand over
- Deliver a written rule inventory with purpose, conditions, actions and owner for every routing rule
- Provide a test script and results so your team can repeat the checks after upgrades or policy changes
- Walk your administrators through the change flow, validation requests and level 3 handoff procedure
- Document the configuration as code-like exports or screenshots agreed in the scope, stored in your environment
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Review routing rules when GLPI releases change business rule behavior or change validation features
- Retest CAB routing after major updates, since plugin reactivation may be needed on GLPI 11 and later
- Quote follow-up work from a written scope that names the rule changes, testing effort and owners
