GLPI equipment reservations: when a loaner pool needs booking
When laptops, projectors or vehicles are shared across a team, the booking usually lives in a spreadsheet, a sign-out sheet on a wall, or a chain of emails. Double bookings follow, and nobody knows which unit is actually free on Thursday afternoon. GLPI reservations let users reserve an asset for a time slot, including recurrent reservations, so the asset record in your inventory also becomes the booking calendar. Before you configure anything, know that assets are not reservable by default. Each item type must be switched on from the Reservation tab of the individual item, so a pool of ten projectors means ten items to review, not one global setting. Confirm with your own GLPI version how the tab appears and who can edit it, since your administrators will need that permission to make the switch.
The decision that matters most is whether a request belongs in a reservation or in a ticket. Reservations suit items with a known start, end and single holder, such as a loaner laptop for a two-day trip or a van for a site visit. A ticket suits work that needs triage, approval, a technician to prepare or hand over the asset, or a record of a fault. Many teams run both: the reservation holds the slot, and a ticket is opened only when the item comes back damaged or a special setup is needed. Map your own request types before you build, so users are not left guessing which path to take.
Plan the pool with the people who will use it, not only the administrators. Decide who may reserve each item, whether recurrent bookings should be allowed for a standing need, and who resolves a clash or a no-show. Check the reservation documentation for the exact recurrence options and the notifications sent to users in the version you run, and test them with a few real items before rollout. Once the pool is live, review the calendar regularly against the asset inventory, because retired or relocated equipment that remains reservable will produce bookings nobody can fulfill. GLPI reservations documentation is the natural next read for the field-level detail.
Which reservation setup fits each loaner pool
Loaner laptops are the pool most organizations start with, and they carry the most account risk. A returned device usually has to be wiped, re-imaged and checked before anyone can borrow it again, so the reservation setup should follow the asset lifecycle your service desk already runs. The first decision is whether a reservation changes the assigned user on the asset record or only blocks a time window.
- Status after return: Set the state a laptop moves to when it comes back, so a device waiting for re-imaging does not look available to borrowers.
- Assignment model: Decide whether a booking changes the assigned user or leaves the assignment alone, and confirm how your inventory agent reports the device afterward.
- Imaging and encryption checks: Name the team that clears each device and record that step somewhere auditable, because a reservation record alone does not show the device was wiped.
- Accessory bundles: Reserve chargers, docks and adapters with the laptop only when your team can keep them together in one pool.
Confirm with your service desk how returned devices move through states today, then test the reservation behavior in the GLPI version you run before you map the process onto it.
Projectors, microphones, cameras and portable displays are shared by many people for short slots, often in the same building. The pool is high volume and conflicts are common, so the setup should focus on how bookings are placed, where the equipment lives and how it is handed over. Physical location matters more here than for laptops, because a projector booked for one room must be where the requester expects it.
- Slot length: Decide the shortest bookable slot and whether a reservation can span a full day, since short slots create more conflicts for popular items.
- Location: Keep each item tied to the entity and room it serves, so requesters only see equipment they can collect.
- Hand-off: Define who releases the item at the start of a slot and who checks it back in, and whether a missing cable or remote is logged on the record.
- Visibility: Limit which users can see or book sensitive equipment, such as recording devices, to the groups that need them.
Check with the teams that run meeting rooms how often equipment moves between rooms, and confirm how GLPI displays the booking calendar to each profile before you publish the pool.
Pool vehicles are reserved for longer periods, usually by people who must meet eligibility rules before they drive. A booking therefore carries more than a time window: it needs a driver, a key handover and a record of mileage and fuel. The setup should also account for maintenance, which can take a vehicle out of service in the middle of a booking that was already made.
- Driver eligibility: Confirm how you record that a requester holds the license class needed for each vehicle, and whether that check happens in the reservation step or before it.
- Key handover: Decide where keys are kept and who signs them out, and record the handover against the booking.
- Mileage and fuel: Capture start and end readings as part of the return, so the asset record reflects actual use.
- Maintenance blocks: Schedule service as its own reservation type so routine work does not appear as a free vehicle.
Confirm with your fleet or facilities team which checks they must evidence, then verify that the reservation form and asset fields can hold that information in the GLPI version you run.
Recurrent reservations suit equipment held on a fixed rhythm, such as a projector booked every week for a training class or a pool vehicle held for a regular route. GLPI supports recurrent reservations, so the question is less whether the feature exists and more how series are owned, changed and retired. A recurring block that nobody reviews can quietly keep an asset out of circulation for months.
- Series ownership: Record which person or team owns each recurring series, so changes come from someone accountable.
- Conflicts with one-off bookings: Decide whether a series takes priority over ad hoc requests in the same slot, and say so in the requester guidance.
- Holidays and exceptions: Plan how a series skips dates such as public holidays without being deleted and recreated.
- Periodic review: Set a recurring review of active series so unused blocks are released.
For each series, confirm the owner, the end date or review date and the exception process before the first booking goes live, and test an edit to one occurrence in a non-production copy of your instance.
Any loaner pool becomes easier to run when requesters can book without asking a technician. The self-service path decides who can see each asset, which requests need an approver and where a request that falls outside the rules is sent. Because the public portal is shaped by the entity and profile a user belongs to, the setup should be tested with a standard user account rather than only with an administrator account.
- Publication: Make reservable assets visible only in the portal areas where the matching requesters work, and confirm the reservation tab is set on each item you publish.
- Approval: Decide which pools need a manager or technician approval and which can be booked directly.
- Fallback routing: Send requests that cannot be booked to a ticket, so the request is tracked instead of lost in email.
- Acceptance testing: Run a booking as a requester in each entity, including a booking that should be refused.
Before launch, confirm with your service owner how approvals are configured in the GLPI version you run, and document the test accounts and results so the setup can be repeated after an upgrade.
Configuration options and when each fits
This table compares the main ways to configure reservable GLPI assets, from a single loaner item to a recurring pool that users book themselves. Read each row against the kind of asset you are lending and how often the same people need it. The main takeaway is that the reservation model should follow the asset's availability pattern, not the other way around.
| Option | What it does in GLPI | When it fits |
|---|---|---|
| Single reservable asset | One laptop or vehicle is made reservable from its Reservation tab and booked for time slots | A small loaner set where each item is booked by one person at a time |
| Pool of identical assets | Several identical items, such as projectors, are each made reservable and booked separately | Shared equipment where users need any available unit rather than a specific one |
| One-off reservations | Users book a single time slot for an asset | Ad hoc needs such as a demo device for one meeting |
| Recurrent reservations | Users book the same asset on a repeating pattern | Standing needs such as a weekly vehicle for a field team |
| Technician-managed bookings | Staff create or change reservations on behalf of users | Teams that hand out equipment at a desk and need to control check-out and return |
| Self-service booking | Users reserve assets themselves through the helpdesk portal | Larger user populations where requests should not queue at the service desk |
| Mixed asset types in one catalog | Different asset categories are made reservable with different owners and availability | Organizations where vehicles, rooms and devices are managed by different teams |
How to set up reservable assets in GLPI
This sequence takes a set of loaner equipment from an inventory record to a bookable pool that staff can reserve for time slots, with recurring bookings where the pool needs them. Each step ends with a check you can run before anyone sees the pool.
Confirm the asset types and entity layout
Before touching any record, decide which asset types make up the loaner pools, such as laptops, projectors or vehicles, and which entity or entities own them. Ask your GLPI administrator to confirm that these asset types exist in the core and that the entity structure matches how your sites share equipment. Write down which technicians manage bookings and which users will reserve. The step is done when you have a short written list of pools, owning entities and managers that the reservation setup will follow.
Create the asset records for each pool item
Create or import one asset record per physical item in each pool, using a consistent naming pattern and the location, status and serial data your inventory already holds. Keep each physical unit as its own record so that a reservation points to a specific item rather than a vague quantity. Your team should confirm the records against the devices on the shelf or in the vehicle pool. The step is done when every loanable unit has an active record in the correct entity and location.
Make each asset reservable from its Reservation tab
Assets are not reservable by default. Open each asset record, go to its Reservation tab and enable reservations for that item. Doing this per item means that equipment you never intend to lend, such as servers or fixed installations, stays outside the booking flow. Ask the administrator to check whether the setting must be repeated for each item or can be applied in bulk through a tool your version offers, and confirm this against the GLPI reservations documentation for your version. The step is done when a test item shows the reservation option as enabled.
Set who can reserve and who manages bookings
Review the profiles and rights that govern reservations so that end users can book the pools they need and technicians can edit, cancel or override bookings. Match these rights to the entity and profile model already used for tickets and assets, and avoid giving general users rights over assets outside their area. Test the result with one account from each group. The step is done when a standard user can book a reservable item, and a manager can see and change that booking, while a user without the right is refused.
Create a test reservation for a single slot
Book one item for a single time slot as a standard user, then check the calendar view and the record of that asset. Confirm that the booking shows the correct item, dates and requester, and that it appears for the technicians who manage the pool. Cancel it and confirm that the slot becomes free again. This first booking reveals mistakes in time zones, entity visibility or item selection before real staff rely on the system. The step is done when the single-slot booking and its cancellation behave as expected in both views.
Test recurrent reservations on a pool item
Create a recurrent reservation on a test item, such as a projector that a team books for a weekly meeting, and check each occurrence in the calendar. Confirm how the series behaves when one occurrence conflicts with an existing booking and how a single occurrence is changed or cancelled without affecting the rest. Record the behavior your team will document for users. The step is done when you have verified the recurrence pattern you plan to allow and know how exceptions are handled.
Publish the self-service path and brief the managers
Make the reservation path visible to end users, typically through the helpdesk portal where reservations can be offered, and give managers a short guide that covers booking, changing, cancelling and handling overdue returns. Confirm with the administrator which entry points your portal version shows to each profile. The step is done when a user with the standard profile can find and complete a reservation without help from a technician, and each pool manager has signed off on the process.
Review the pool data after the first cycle
After the pools have run for a full working cycle that your team defines, review bookings, cancellations, conflicts and asset status changes against the expected behavior. Ask whether the asset records still match the physical items, and whether any pool needs a different set of rights or recurrence rules. Note the changes to make and assign owners for them. The step is done when the review has produced a documented list of adjustments, and the pool managers have confirmed that their daily process matches the setup.
Access, visibility and audit risks for shared equipment
A loaner pool is only as trustworthy as the records behind it. The risks below sit in the same place: who can book an asset, who can see other people's bookings, and what the history shows after something goes missing or breaks. Check each one before the pool opens to users.
Who can make an asset reservable
Assets are not reservable by default. Enabling reservations is a per-item action on the Reservation tab, so the person who can edit an asset effectively decides which equipment enters the pool. Confirm which GLPI profiles can change that setting, and keep the list short for high-value items such as vehicles or conference hardware. Review the setting when an asset is retired or moved to a different entity so stale availability does not carry over.
Visibility of other users' bookings
A reservation calendar shows when an asset is taken and often by whom. Decide whether requesters should see only free and busy time or the name of the person holding an item. Test this with a standard user account, not an administrator, because administrator views often hide the restriction you intended. Entity and profile rights should determine the answer, and you should confirm that behavior in your own GLPI version.
Recurring bookings and ownership drift
Recurrent reservations keep taking a slot after the original requester changes role or leaves. A weekly booking for a projector can outlive the person who made it, and the item then looks busy to everyone else. Set a review step for recurring series, define who may cancel a series on someone else's behalf, and confirm how GLPI handles bookings tied to a deactivated user account before you rely on it for offboarding.
Audit trail for custody and condition
When a laptop returns damaged, the question is who had it last and in what state. The reservation record only answers that if returns are logged against the booking, not left to memory. Define the minimum record for check-out and check-in, including condition notes, and confirm which GLPI history entries you can retrieve and for how long your own retention policy requires keeping them.
Access to the self-service path
The self-service path puts the booking form in front of every user who can reach the portal. Anyone with an account can request equipment, so unauthenticated or guest access should be off unless you have a deliberate reason. Pair the reservation path with your authentication design, and confirm how external sign-in sources such as LDAP or a web server SSO layer map to the profiles that can book.
Sensitive assets and location data
Some pooled items reveal more than their model name. A vehicle booking can expose a site, a route or a driver, and a device booking can reveal a team's location. Limit which fields appear on the public reservation view, and keep sensitive asset details inside the entity that owns them. Test this with a user from another entity before the pool goes live.
Questions teams ask before running loaner pools in GLPI
Can GLPI reserve laptops, projectors and vehicles without custom development?
Yes, GLPI's reservation feature works on asset types your team already tracks, so laptops, projectors and vehicles can be reserved once they are in the inventory. Assets are not reservable by default, so each item must be switched on individually from its Reservation tab. The work that remains is the inventory itself: consistent asset records, clear naming, and a decision on which models belong in the pool. Confirm in a test instance how your GLPI version presents reservations for each asset type before you promise the feature to users.
How much effort does setting up a loaner pool take?
Effort depends mostly on how clean your asset data already is. A pool of a few dozen items with accurate serial numbers, locations and status is a configuration exercise, while a pool built from unlabeled spreadsheets needs cleanup before any reservation is useful. Other drivers include the number of sites or entities, how many approval rules you need, and whether the pool shares a helpdesk portal with other services. A written scope should list each asset type, each location, and each user group that will reserve items, so the quote reflects the actual work.
Who pays for the loaner pool work, and what recurs afterward?
Most of the cost is one-time: planning, configuring asset types and reservations, data cleanup, testing with pilot users and documenting the process. Recurring costs sit in running the platform, which includes server capacity, database backups, GLPI upgrades and plugin maintenance. If you use a partner, ask the quote to separate build work from ongoing support, and ask who owns the configuration after handover. GLPI itself is distributed under the GNU General Public License version 3, so software licensing for the core is not a per-user charge, but commercial add-ons and hosted options have their own terms.
Can recurrent reservations cover weekly or monthly loans?
GLPI supports recurrent reservations, so a user can book the same asset on a repeating schedule, such as a projector for a weekly team session. Before you rely on this, decide which recurrence patterns your organization actually needs and test them with real calendars, including holidays and handovers between users. Confirm how recurrent bookings interact with maintenance windows and whether a booking can be cancelled for one occurrence without cancelling the series. Document the answers so that help desk staff handle exceptions the same way every time.
What goes wrong when users reserve equipment themselves?
The common failures are double bookings caused by unclear pool boundaries, reservations for assets that are already out for repair, and items returned without a status update. Self-service also fails when users cannot see which items are reservable or when the reservation form asks for information nobody has. Prevent these by keeping asset status accurate, limiting each pool to one asset type where possible, and setting a clear return procedure. Run a pilot with one team, collect the failed bookings for two or three weeks, and fix the configuration before rolling out to the whole organization.
Should a loaner pool sit in the helpdesk portal or in a separate catalog?
Either can work, and the choice depends on who uses the pool and how much friction users will tolerate. Placing reservations in the self-service portal keeps requests in one place, which helps staff who already use the portal for incidents. A separate entry point is clearer when loans are common and not related to support work. Test both options with a few real users and check that the path from the home page to a booking takes few steps. The portal layout is a separate topic, so plan that design alongside this one rather than after launch.
Does tracking loaned devices create security or privacy obligations?
A reservation log links people to devices and dates, so access to that data should follow your internal rules for personal information and asset records. Decide who can see reservation history, how long records are kept, and what happens to a device's assignment history when a user leaves. Devices that leave the building also raise endpoint concerns, such as encryption and remote wipe, which sit outside GLPI's reservation feature. Ask your security and privacy leads to review the design before launch, and do not treat this review as a formal compliance attestation, since only independent auditors can issue one.
How do we upgrade GLPI later without losing reservation settings?
Plan upgrades as a standard GLPI change with a backup first, because reservation settings live in the database and configuration files. The GLPI update procedure requires backing up the database, the files, and the config directory including glpi.key and glpicrypt.key, then replacing the application files and running php bin/console db:update. Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates, so check any plugin that touches assets or bookings. Test the upgrade on a copy of production before scheduling it, and confirm reservation behavior after the change.
How DeployOpen scopes and delivers GLPI reservation pools
DeployOpen plans, builds, documents and supports GLPI reservation pools inside infrastructure you control. We start from the assets you want to lend, the people who book them and the rules that govern each pool, then agree the scope in writing before work begins.
How we scope
- Inventory the loanable asset types, such as laptops, projectors and vehicles, and confirm which items will be made reservable
- Map who may book each pool, how far ahead bookings are allowed and which recurrent patterns the business actually needs
- Agree the written scope, deliverables and timeline for the reservation pools before any configuration starts
How we build
- Enable reservations on each chosen item from its Reservation tab and set up the pool structure in a test instance first
- Configure recurrent reservations and the self-service request path so users can book without raising a ticket
- Test booking, conflict, cancellation and recurrence scenarios with a representative set of users before production rollout
How we hand over
- Document the pool catalog, booking rules, ownership of each asset and the steps for adding new reservable items
- Train the administrators and asset owners who will manage pools, approve exceptions and resolve double bookings
- Deliver the configuration record and test results so your team can repeat the setup or audit it later
How we support
- Offer ongoing support, upgrades and continuous testing for reservation pools as a retainer alongside your GLPI platform
- Review reservation rules and pool ownership when GLPI versions change, including the plugin reactivation steps after major updates
- Confirm with your team which support levels, response expectations and change windows apply before the retainer starts
