GLPI business rules for ticket routing: what they automate and when to use them
Service desk leads usually recognize the same symptoms: tickets land in the wrong group, categories are picked differently by each person who logs a request, and SLA clocks depend on whoever happens to triage. GLPI business rules automate ticket assignment, categories, SLAs and entities at ticket creation and update, so the same request gets the same routing every time. Rules are a good fit when the routing logic is stable and can be described as conditions on fields that already exist, such as requester, location, ticket title, source channel or category. Manual triage remains the better choice for requests that need judgment, for tickets that arrive with incomplete information, and for work where a senior person should decide priority. A useful first step is to list the five or six misroutes that cost the most time last quarter and check whether each one has a predictable pattern.
Before writing rules, confirm the exact criteria and actions available in the GLPI version you run, since GLPI 11 and GLPI 12 may differ in how rule conditions and actions are labeled and ordered. Rules run in a defined order, and the first matching outcome can change fields that later rules then read, so the order is part of the design. Plan a test set of representative tickets for each entity and category, run it against a non-production instance, and record which rule fired and what it set. Also decide who owns the rule set, how changes are reviewed and how the rules are documented, because routing logic that nobody can explain becomes the next source of wrong assignments.
Be clear about the limits. A business rule can fill or change fields when a ticket is created or updated, but it should not be expected to silently overwrite values an agent has entered deliberately, and the behavior on manual edits must be verified in your version. Test whether rules re-run on update and whether they respect fields a technician has already set. Where your routing depends on data that lives in other systems, such as directory group membership or asset ownership, confirm how GLPI receives that data before relying on it in a rule. Your implementation partner can help you map these checks to your environment before the rules go live.
Rule types and actions: which outcome each option fits
This table compares the ticket outcomes business rules can set against the criteria a team usually routes on, so you can see which combinations fit your service desk. Read each row as a question: what does the team want to happen, and what must be confirmed in the installed GLPI version before building it. The main takeaway is that the rule editor, not this page, is the source of truth for available criteria and actions.
| Desired outcome | When the option fits | What to confirm in your installed version |
|---|---|---|
| Assignment to a user or group | Tickets from a known requester group, site or service should land with a named first-line team without manual triage. | Check the rule editor for the assignment actions offered, and test whether group assignment and user assignment can be set in the same rule. |
| Category | Incoming tickets share recognizable keywords or source, and a consistent category drives reporting and downstream routing. | Confirm which criteria can match on title or description text and whether the category action fills an empty field or overwrites an existing value. |
| Priority or urgency | A specific service, location or requester always needs a higher urgency than the default, for example a critical business unit. | Confirm whether the rule sets urgency, priority or both, and how the priority matrix combines them in your configuration. |
| SLA and OLA | Tickets for a contracted service need the correct service level targets applied at creation, rather than relying on agents to pick them. | Check that the SLA and OLA actions are listed in the rule editor and that the calendar and targets are already defined before the rule is tested. |
| Entity | Requests from a specific customer, site or organization belong in a separate entity, so access and reporting stay separated. | Confirm which criteria can route to an entity, and whether requester entity or profile rules must also be aligned for the ticket to be visible. |
| Default values | A field should carry a standard value when the requester does not supply one, such as a default source or request type. | Confirm whether the default action applies only on creation and whether agents can still change the value afterward. |
| Requester or location criteria | Routing depends on who submitted the ticket or where the asset or user sits, which is common for multi-site support. | Check which requester, user and location fields are available as criteria and whether they are populated reliably for email and portal tickets. |
| Title or source criteria | Email-created tickets and portal forms carry consistent subject lines or origin markers that identify the request type. | Test with real sample tickets from each channel, since keyword matching depends on the exact text the requester sends. |
Which intake path changes how routing rules behave
Requesters who submit through the self-service interface or a catalog form usually send the most complete data at creation, because the form controls which fields appear. The rules can see the requester, their entity and group membership, the category and request type the form sets, and any custom fields the form collects. Fields the requester never sees, such as the assigned technician, the assigned group and often urgency, are usually empty when the rules first evaluate.
- Requester context: The requester's entity and profile come from their account, so entity-based criteria usually have data to match. Confirm this against how your users and entities are set up.
- Form-driven fields: Category and request type come from the form choice. Check that each form option maps to the category you expect.
- Empty at creation: Assignee, assigned group and sometimes priority are blank, so rules that set them must not depend on those fields already being filled.
- Template effects: A ticket template that hides or predefines a field changes what the rule sees, because the template default is what gets evaluated.
- Catalog routing: If a catalog item carries its own category or group, confirm whether rules can override it and in which order.
Test first by submitting one ticket from each form and from each requester profile, then compare the category, entity, group and priority on the result with what you intended.
Tickets created from mail have the sender address, subject, body, attachments and the address the message was sent to. The rules can match on any of these, but the sender may not be a known GLPI user, and the category, urgency and group are usually empty. Mail also arrives in forms the rules were not designed for, such as replies, forwards and automated notifications, so the parsed content can differ from what a technician expects to see on a web form ticket. Configuring the receivers themselves is covered in the sibling topic on turning email into GLPI tickets with receivers.
- Recipient address: The address a message was sent to is often the most reliable routing signal, especially when one mailbox serves several teams.
- Sender matching: Unknown senders may create tickets without a linked requester, so criteria based on requester group or entity can silently fail.
- Subject parsing: Keywords in the subject are the usual trigger for category rules, which makes them sensitive to wording changes by requesters.
- Replies and forwards: Follow-up mail may attach to an existing ticket or open a new one, so confirm how threading behaves before relying on rules for those messages.
- Automated mail: Monitoring alerts and out-of-office messages can match your rules by accident, so decide how they should be filtered first.
Test with a mailbox you control: send from a known user, an unknown address, a reply and a forwarded message, and record which rules fired on each.
Tickets created through the API or an integration contain only what the calling system sends, plus any defaults the integration account inherits. The rules can see the fields in the payload and the permissions of the account that made the call. Fields the payload omits, custom fields that the integration never fills, and any values that depend on a later lookup are usually empty, so the rule logic has to handle missing data as a normal case.
- Payload mapping: A field that the source system names differently may never reach the rule, so check each mapped attribute on a sample ticket.
- Service account scope: The entity and profile of the integration account determine what the ticket can see and be assigned to. Confirm both before writing entity-based rules.
- External identifiers: Store the source system's reference in a field the rules can match, so related tickets route consistently.
- Retries and duplicates: A retried request can create the same ticket twice, and each copy evaluates the rules again. Confirm how your integration prevents this.
- Timing: Some integrations create the ticket and then update it in a second call, which fires update-triggered rules as well as creation rules.
Test first by replaying sample payloads, including ones with missing or malformed fields, and by sending the same request twice to see what the rules do.
Technicians create tickets on behalf of requesters by phone, in person or from a monitoring follow-up. The technician enters the data, so most fields can be populated, but the values are often partial or chosen quickly. The rules can see everything the technician enters, along with the technician's own entity, group and profile. Because the technician may set values the rules also target, the order and trigger conditions of the rules decide whether a deliberate choice survives.
- Manual overrides: A rule that sets a category or group may overwrite a value the technician chose, depending on how the rule is configured. Confirm the behavior with a test ticket.
- Creation on behalf of a requester: The requester context may come from the person being helped, not the technician, so check which entity the ticket lands in.
- Update triggers: Rules that run when a ticket changes can fire during normal work, such as reassignment or status changes, and undo a manual decision.
- Partial data: Technicians may leave urgency or impact blank, so rules that depend on the priority matrix need a defined fallback.
- Bulk actions: Mass updates can evaluate rules across many tickets at once, which makes a faulty rule more costly to undo.
Test first by creating a ticket as a technician, setting a category or group by hand, and confirming that the saved value stays in place after rules evaluate.
Set up routing rules in order, with checks at each stage
This sequence moves GLPI business rules from a written routing matrix to a tested, production-enabled set, with a check at every stage so each rule is proven to assign the expected group, category and SLA before it touches live tickets. It also leaves a rollback plan that the service desk can execute without the build team.
Export current categories, groups, entities and SLAs
Export the ticket categories, groups, entities, SLA and OLA names from the production instance, using the GLPI list views or a database read by someone with administrator access. Store the export with a date so every rule refers to a fixed inventory rather than memory. Confirm that each name a rule will reference appears exactly once in the export, because duplicate or renamed items are a common cause of rules that match nothing. The step is complete when the team has a reviewed list signed off by the service desk lead.
Agree a routing matrix with the service desk
Write a matrix with one row per intake path and request type, listing the conditions (requester entity, category, urgency, keywords in the title), the target group, the category, the SLA and any fields to set. The service desk lead, the owners of each receiving group and the entity administrators should approve it together. Mark which rows may override a value a human has entered and which must leave it alone. The step is complete when every row has a named owner and the matrix has been approved in writing.
Build the rules in a non-production instance
Create the rules in a non-production GLPI instance that holds a copy of the production groups, entities and SLAs, which is why the export in the first step matters. Give each rule a name that states its purpose and its matrix row, so the rule log is readable later. Keep the rule types consistent with the matrix and do not add conditions the matrix does not mention. The step is complete when each matrix row maps to exactly one rule, and the team can point to that rule by name.
Order rules from most specific to most general
Arrange the rules so that narrow conditions, such as a specific requester entity combined with a category, are evaluated before broad fallbacks, such as a default group for any ticket. Rules are applied in the order they appear, so a broad rule placed first can stop more specific rules from running on the same ticket. Review the order against the matrix and record the final sequence in the change record. The step is complete when a reviewer can explain, for any ticket, which rule should match first and why.
Test with sample tickets from each intake path
Create sample tickets through each intake path the matrix covers, including the web form, email-to-ticket receivers, and any API or agent channel in use, and record the expected group, category, priority and SLA for each. Compare the saved ticket with the expected values, and repeat the test for edge cases such as tickets that match two rules and tickets that a person has already set manually. The step is complete when every sample ticket shows the expected group and category, and every mismatch has a documented fix and a retest.
Review the rule log and ticket results
Check the rule execution log for the test tickets to confirm which rules fired, in what order, and which values they changed. Confirm that rules did not overwrite values that the matrix marks as manual, and that no ticket was left without a group. Ask the service desk lead to review a sample of results against the matrix before anyone proceeds. The step is complete when the log shows the expected sequence for each sample and the service desk has signed off the results.
Enable the rules in production
Enable the approved rules in production during a window agreed with the service desk, and keep the change record open until the first live tickets have been checked. Watch the first batch of new tickets for unassigned items or unexpected categories, and compare them with the test results. Confirm the instance's own configuration and any rule-related settings against the vendor documentation before the change, rather than relying on the test instance. The step is complete when the first live tickets match the matrix and the change record is closed.
Record a rollback plan and its owner
Write the rollback plan before enabling the rules: the steps to disable or reorder the rules, who may do it, and how the service desk will be told. Store a copy of the rule configuration exported before the change, so the team can restore the previous state. Test the rollback on the non-production instance so the steps are known to work. The step is complete when the rollback plan has a named owner, has been tested once, and is attached to the change record.
When rules cannot override manual values
Business rules fire on events and fill in values, but they do not always win against what a person already entered or what a template locks. Several conditions decide whether a rule's output sticks, so the service desk should check each one before promising routing or categorization to stakeholders.
Values entered before the rule runs
A rule that sets an assignee, category or SLA only fills fields when the rule actually changes them, and a value a requester or technician typed before the rule executes can survive. Check whether your rule is set to assign only when the field is empty or to overwrite unconditionally, and test both paths with a ticket created manually and one created by email. Confirm in your installed version how the rule treats fields already populated at creation, since behavior around update events differs between rule types.
Fields locked by ticket templates
Ticket templates can make fields mandatory, hidden or predefined, and a predefined value in a template may be applied before any rule runs. A rule that tries to change a field the template has fixed can appear to do nothing. Review the template attached to each request type and category, then confirm the order of template application and rule execution in your GLPI version before you describe the outcome to the business.
Rules that run only on creation
Some rule types evaluate only when a ticket is first created, so later edits to category, urgency or requester do not trigger a new routing decision. A ticket that is reclassified by a technician will keep its new value even when it matches a rule. Document which events each rule responds to, and plan a separate process, such as a manual step or a second rule on update, for tickets whose details change after intake.
SLA clocks already started
Once a ticket's time-to-own or time-to-resolve clock has started, changing the SLA through a rule does not reset elapsed time, and a change may only affect the targets that follow. Stakeholders often expect a re-routed ticket to inherit a fresh deadline. Confirm with a test ticket in your version whether a rule-applied SLA recalculates the existing clock, and record the answer in your operating procedure.
Entity and profile restrictions
A rule runs within the entity context that applies to the ticket, and the acting user's profile and entity access determine which tickets they can see and edit. A technician who lacks rights in the target entity may not be able to keep an assignment or category that a rule produces. Map each routing outcome to the groups and profiles that must hold it, and verify with a user from each profile that the result is visible and editable.
Empty criteria fields
A criterion that references a field with no value on the incoming ticket may evaluate differently from what the rule author expects, so a rule can match too broadly or not at all. Empty requester groups, blank titles from email and missing location values are common causes. Decide per rule whether an empty criterion should match, and write a test case for a ticket that lacks each criterion field before enabling the rule in production.
Testing rule order without disrupting live queues
Test every new or reordered business rule on a copy of production data before it touches a live queue. A staging instance restored from a recent database backup, with the same entities, groups, categories and SLAs, is the safest place to check how a rule set behaves. Run a set of representative tickets through it: a password reset from a VIP user, a network outage reported by email, a change request in a sensitive entity and a ticket that matches no rule at all. Confirm the ticket lands in the right entity with the right category, group and SLA, and that rules which should not fire stay silent. Because business rules act on ticket creation and updates, a pilot should cover both paths, since a ticket created correctly can still be reassigned when someone edits it. Confirm with your own administrators how the staging copy handles email receivers and notifications so that test tickets do not send mail to real users.
Order rules so that specific exceptions run before general defaults, and assume overlaps will happen. GLPI evaluates business rules in their configured rank order, and a later rule can overwrite a value set by an earlier one. A broad rule that assigns all hardware tickets to a field group can silently undo a narrower rule that routes printer tickets for a specific site to a local team if the broad rule sits higher. Before go-live, list every rule that writes the same field (group, category, entity, SLA or priority) and read them in order as a single sequence. Document the intended final result for each test ticket, then compare it with what the pilot produced. Treat a difference as a design defect to fix in the rule criteria, not as a quirk to accept, and keep the number of rules writing the same field as small as your routing model allows.
Review the actual outcome of the pilot in ticket history and rule logs, then record every change so the routing can be explained later. After each test run, open the history tab of the sample tickets to see which fields changed, in what order and under which user or automatic action, and compare that with the intended result. Check the GLPI logs for rule processing where your version exposes them, and confirm with your administrators which log level and retention apply in your deployment. Keep a short change record for each rule: its purpose, the fields it writes, its position, the test tickets used and the reviewer who approved it. When a manager later asks why a ticket went to a particular group, that record, together with the ticket history, should give a clear answer. Ask any implementation partner to deliver this record as part of the scope, since it is what makes routing auditable after the project team has left.
Security and operational considerations for routing rules
Routing rules decide who sees a ticket, which entity owns it and how it is classified, so a bad edit can misroute or expose customer data at scale. The cards below cover who can change rules, how entities keep rules from crossing boundaries, and how to protect and re-test the rule set through upgrades.
Restrict who can edit rules
Business rules are administrative configuration, so limit edit and creation rights to a small named group of GLPI administrators rather than general helpdesk staff. Review which profiles hold the rights to the rules engine, since a technician with broad configuration access can change assignment logic for every queue. Confirm this in your own environment by testing the rights of a standard technician account before go-live.
Keep routing inside entities
Rules that assign tickets, categories or SLAs must be scoped so a match in one customer or business unit cannot pull tickets into another entity. Test each rule with tickets created from every entity that could trigger it, and check that the entity condition is evaluated before any assignment action runs. Illustrative example: a broad keyword rule without an entity condition could move a competitor's ticket into your queue.
Put rule edits under change control
Treat each rule change as a configuration change with a written reason, a named approver and a test case that proves the intended behavior. Export or document the rule order before editing so a rollback is possible. Because rule order changes outcomes, a change that looks local can reassign or reclassify tickets already flowing through other rules.
Back up before every upgrade
The GLPI update procedure requires a backup of the database, the application files and the config directory, including the glpi.key and glpicrypt.key files. Without the key files, encrypted values cannot be recovered from the backup. Store backups outside the GLPI host and test a restore on a separate instance, so the rule tables and their conditions can be recovered if an update goes wrong.
Re-test rules and plugins after updates
In GLPI 11 and later, plugins are suspended when a new version is detected and must be reactivated after major updates. Routing rules that depend on plugin fields or actions can stop matching silently, so plan a post-update test pass. Replay a set of reference tickets through the rules, confirm assignments, categories and SLA values, and reactivate plugins only after the checks pass.
Audit rule changes and outcomes
Confirm that GLPI's history and logs capture who changed a rule and when, and keep those records with your change tickets. Also review tickets that were routed by rules over time, looking for unassigned work, unexpected categories or SLA values that do not match the contract. Ask your team to confirm which audit records are retained in their GLPI version and how long they are kept.
Questions teams ask before routing rules go live
What drives the effort of a GLPI routing rule design?
The effort follows the number of routing decisions, not the number of rules in the final file. Each distinct path needs a clear input (entity, requester group, category, location, keywords in the title or sender address), a clear output (assigned group, category, urgency, SLA or entity), and an agreed owner for exceptions. Teams with few entities and a short category list usually finish design quickly. Effort rises when categories overlap, when several entities share service groups, when the service desk has no written category model, or when rules must match on fields that arrive inconsistently from email, forms or agents. Ask any partner to show the decision table before they quote, because that table sets the testing load.
Can our internal staff build GLPI business rules without a partner?
Yes, a capable GLPI administrator can build and test business rules in-house, provided someone owns the category model and the routing decisions. GLPI's rules engine is configured through the web interface, so the technical barrier is moderate. The harder work is agreeing the decisions: which group owns which category, which fields are authoritative, and which manual changes must survive a rule run. Internal teams often underestimate regression testing, because a rule change in one entity can alter tickets created by another. A partner adds most value when the design spans several entities, when rules must be exported and reviewed under change control, or when the team lacks time to run structured tests before go-live.
What does the service desk and asset team need to provide?
The service desk must supply the category tree, the current routing practice, and examples of tickets that were misrouted last quarter. Asset owners must confirm how computers, applications and locations are recorded, because routing that depends on asset data fails when asset records are stale. Entity owners must confirm which teams sit in each entity and who approves changes to routing. Named reviewers are needed for test sign-off. Without these inputs, the design becomes a set of assumptions that surfaces only in production. Ask your partner to list these inputs in the written scope so that delays are visible and attributable.
How long does a routing pilot take across many groups and categories?
The duration depends on how many groups and categories must be tested and how many people must approve results, so no fixed figure applies across environments. Plan the pilot around a sample of real ticket types for each group, run rules against that sample in a test or staging instance first, and review every unexpected assignment. Add time for a second round whenever a category boundary changes. Ask any provider to state the number of groups, categories and entities in scope, the test cases they will run, and the sign-off steps, then compare those counts with your own inventory before accepting a timeline.
How do business rules differ from SLA escalation and the priority matrix?
Business rules decide what happens when a ticket is created or updated, such as setting the entity, category, assigned group or urgency. Escalation levels act later, reassigning or notifying when an SLA deadline approaches or passes. The priority matrix computes priority from urgency and impact using a fixed grid. These mechanisms interact: a routing rule that sets urgency changes the priority, and an escalation criterion may depend on the group a rule assigned. Design the three together so that a rule does not create a ticket state that an escalation later treats as untouched. Review the order of operations in one written map before enabling any of them.
What changes for routing rules after a GLPI 11 to 12 upgrade?
Confirm the changes in the official GLPI 12.0.0 release notes and in your own test instance before planning the upgrade. The release notes list group-managed OLAs among the changes, which affects how service levels attach to groups and therefore how routing and SLA logic should be checked. Re-run every routing test case after upgrading, including rules that touch entities, categories and assigned groups. Back up the database, files and the configuration directory, including the encryption key files, as the upgrade documentation requires, and plan for plugin reactivation, since plugins are suspended after a new version is detected in GLPI 11 and later releases.
What does a fixed-scope routing engagement typically include?
A fixed-scope engagement at DeployOpen usually covers agreed deliverables written before work starts: a routing and categorization design, the rule set configured in the agreed GLPI instance, a test plan with recorded results, and handover documentation for your administrators. Exact inclusions, exclusions and timelines are defined in the written scope, so ask for an explicit list of entities, groups, categories and test cases. Ongoing rule maintenance, upgrade testing and continuous review are available as retainers. DeployOpen does not publish a price list, so a quote follows from the scope you agree. Ask what is one-time and what recurs.
Limits to confirm in your GLPI environment
Business rules look simple until they meet your GLPI version, your entity structure and the other ways tickets enter the system. The cards below are the points to confirm in your own instance before you write a rule set, so that routing and categorization behave the way your service desk expects.
Available criteria and actions
The criteria a rule can test and the actions it can set vary by GLPI version and by the object type the rule applies to. Before designing routing, list the fields you need to match on, such as category, requester group, location or source, and confirm that each one is available as a criterion and that the actions you need, such as assigning a group or setting a category, are offered for tickets in your version. Check this on a test instance running the same version you will deploy.
Creation only or every update
A rule can be evaluated when a ticket is created, when it is updated, or both, and the answer changes what happens when a technician edits a ticket later. Confirm for your version whether the rule set you plan runs on update, and whether a manual change made by a technician can be overwritten by a later rule run. Decide in advance which fields a human may set and still expect to keep.
Interaction with templates and mandatory fields
Ticket templates can predefine fields, hide them or make them mandatory, and rules can also set field values. Confirm the order in which a template, the form submission and the rule engine apply values, and whether a rule can change a field that a template has locked. A rule that fills a category the template requires may behave differently from one that tries to overwrite a value the requester already chose.
Fit with the entity model
Rules can be scoped to entities, which matters if you run one GLPI instance for several customers, business units or subsidiaries. Confirm whether a rule defined at the root entity applies to child entities as you expect, and whether a rule can route a ticket into another entity without changing the requester's access. Test one case per customer boundary before you rely on the hierarchy for separation.
Email receivers and API tickets
Tickets created by a mail receiver, by the REST or other API, or by a form may reach the rule engine with different input data, such as a sender address that is not a known user. Confirm which rule set applies to each channel, whether the receiver's own routing rules run before the business rules, and whether an API-created ticket receives the same categorization. Send one test message per channel and record the final assignment.
Confirming behavior with the vendor and docs
Documentation for your exact version and the vendor's guidance are the authority on rule behavior, not general forum answers or older screenshots. Ask whether the behavior you need is documented for your release, and whether any known issue applies. Keep a short test script with expected results, and rerun it after each GLPI upgrade, because rule behavior can change between releases.
How DeployOpen scopes and delivers GLPI routing rules
DeployOpen treats GLPI business rules for ticket routing and categorization as a written, fixed-scope workstream inside a GLPI instance that runs in infrastructure you control. The work starts from your routing matrix and ends with rules that are tested, documented and handed to the people who will maintain them.
How we scope
- We map which ticket attributes drive routing, including category, requester, entity, location and urgency, before any rule is written.
- The written scope lists the rule sets, the entities they apply to, and which fields staff may still override by hand.
- We agree a test matrix of sample tickets with expected assignments, categories and SLA values as part of the scope.
How we build
- We configure rules in the GLPI business rules engine for tickets, ordering them so that broader rules run before narrower exceptions.
- We build each rule set in a non-production GLPI instance first, then run the agreed test tickets against it and record the results.
- We confirm with your team which rule actions can be overridden manually and which are locked, and configure the rules to match that decision.
How we hand over
- You receive a rule inventory that lists each rule, its order, its criteria, its actions and its owner.
- We document the test matrix and the results so your administrators can rerun the checks after a GLPI upgrade or a rule change.
- Administrators are walked through how to add, reorder and disable rules, with the change steps recorded for your own change process.
How we support
- Ongoing support, rule reviews and upgrade testing are available as a retainer alongside the fixed-scope build.
- When your category model or service catalog changes, we revise the affected rules under a new written scope.
- Before a GLPI version upgrade, we retest routing and categorization so that assignments do not change unexpectedly in production.
