Skip to content

Booking Policy screen

The Booking Policy screen is where admins configure the four rules that govern how members make bookings and report squawks within a syndicate: whether bookings need admin approval, the minimum booking duration, how far ahead members can book, and whether member-reported squawks need admin confirmation before they become active.

Three of these apply uniformly across every asset in the syndicate. Max Advance Booking Days is the one exception: it follows the default-and-per-asset cascade, so a multi-asset syndicate can override the window per asset.

  • Admin — can change every field on this screen.
  • Members — do not see the Booking Policy screen. They experience the effects (pending status, duration validation, advance-window rejection) indirectly.

In the app:

  1. Open the syndicate.
  2. Go to the Admin tab and tap Booking policy.

Route: /syndicates/:syndicateId/settings/booking-policy.

The screen has two cards: Booking Policy and Maintenance Settings.

Field Default Notes
Require booking approval Off Toggle. Subtitle: “New bookings need admin approval before being confirmed”. When on, a regular member’s booking starts as pending and an admin must approve or reject it. The member’s Create Booking dialog says so above its buttons (“An admin must approve this booking before it is confirmed. Until then it shows as Pending.”) and its button reads Request booking instead of Create. Admin bookings, maintenance windows, events and tentative holds are unaffected, and so is a member’s booking that has already ended when they make it (see the behaviour rules below).
Minimum booking duration (minutes) 60 A whole number of minutes greater than zero; invalid values cannot be saved. Blank falls back to the system default of 60. The validator rejects shorter time-slot bookings.
Max Advance Booking Days 90 A whole number of days from 1 to 365; anything else is refused with a message. Blank falls back to the system default of 90. Cascades per asset — see Default and per-asset settings. A member trying to book further ahead is shown the window rule with the asset’s effective limit.
Field Default Notes
Require admin confirmation for squawks Off Toggle. Subtitle: “When enabled, squawks from members must be confirmed by an admin before they become active”. Off by default, so a member-reported squawk is active (and grounding, if that severity) immediately. When on, a member-reported squawk enters the pending state and an admin must confirm it before it takes effect on airworthiness.

Each numeric field’s label sits above its box, and an empty box shows the default it falls back to (Default: 60, Default: 90). Leaving a field blank saves nothing, so the syndicate follows the default rather than pinning today’s figure.

Settings are persisted on Save Policy.

  • Admin bookings are never held for approval. Even with the toggle on, only regular-member bookings enter the pending queue. See Booking statuses.
  • A booking that has already ended is not held for approval. A member who flew without booking can add the booking themselves if it started no more than 4 hours ago. Once its end has passed it is confirmed straight away, because the flight is over and there is nothing left to approve, and every admin gets a Booking added late notification. A booking that is still running, or runs on into the future, is held for approval as usual. See Record a flight that was not booked.
  • Tentative (pencilled-in) bookings are not held for approval until confirmed. A tentative booking that a member later confirms enters the pending queue at confirmation time if approval is required. See Tentative bookings.
  • Changing Minimum Booking Duration does not retroactively invalidate existing bookings. The validator only runs on new bookings and edits.
  • Max Advance Booking Days is the only cascading field on this screen. On a multi-asset syndicate, the value on Booking Policy is the default — each asset can override it on that asset’s Edit screen, with the same 1 to 365 range.
  • Squawk confirmation can be toggled at any time. Pending squawks from before the change keep their state; new squawks use the new rule.