Product · Booking rules
Two controls,
both enforced on the server.
How long a booking has to be, and whether the facility is open to the person asking. That is the whole model, and we would rather tell you that up front than sell you a rules engine you would go looking for.
01: Capability
Two primitives. Honestly described.
LiteHQ does not evaluate a prioritised list of rules, and there is no way to express “deny this room on this date”. If you need a room closed, you change its availability. Everything on this page is something you can go and verify in the product today.
- Minimum duration
Two fixed minimums, one for members and one for everyone else. The wizard picks the right one as you book, on a single question: does this person hold an active membership.
30 minutes for members, 2 hours for everyone else. - Availability
The switch that actually turns bookings off. Take a facility off online booking entirely, restrict who can see it, or give it a start and end date.
One facility, one date range at a time. - Enforced server-side
The availability checks run on the server, not in the browser. A facility that fails any of them returns a 404 from the booking wizard.
A shared or guessed URL does not get around it.
02: Minimum duration
One setting, split by membership.
There are two minimums, one for members and one for everybody else. The wizard picks between them based on whether the person booking holds an active membership. They are fixed in the product, not something set per facility.
- Filters the dropdownDurations shorter than the minimum are removed, not rejected after the fact
- Bumps rather than errorsA wizard opened on a shorter duration is raised to the minimum
- One boolean, not a ladderMember or not. No tier reads through to booking rules
03: Availability
The gate that actually turns bookings off.
This is what to reach for when you need a room closed. Every check below runs on the server, so a facility that fails any of them returns a 404 from the booking wizard.
- Takes online bookings
Turn this off and the facility is internal. It takes no online bookings from anyone.
- Publicly listed and privacy
A facility is reachable from the public booking link only when it is publicly listed and its privacy is public. Privacy has three values: public, members (hidden from the public link, still bookable by a signed-in member), and limited (admin only, so only an operator booking on someone's behalf can put a booking on it).
- Status
Anything other than active takes the facility offline immediately. This is the toggle in the facilities list, and it wins over the availability window.
- Availability window
A start date, an end date, or both. Compared against today they produce three non-live states: scheduled (not bookable yet), ended (the end date has passed), and inactive (status is not active).
04: Stored but not applied
There is no rules engine behind these names.
These are column names in an orphaned policy row, not features. There has been no form to edit them since May 2026, and since #2601 nothing reads them either. None are checked when a booking is made, so do not plan around one as a control.
We would rather list them here than let you find out from a booking that should not have been possible. The intent is to build the ones that earn their place, enforced on the server rather than in a form.
- Maximum booking duration
- Buffer time between bookings
- How far ahead bookings may be made
- Requiring approval for a booking
- Requiring check-in
- Restricting bookings to credits or tokens
- Auto-cancelling a booking that is not checked into
- Booking reminders and how long before to send them
- Limits on start times
- Recurring-booking limits and how far they may span
See exactly what it does.
Set a minimum duration, close a room, and try to book it anyway. The whole model takes about ten minutes to test, which is rather the point.