Booking Policy screen
What it is
Section titled “What it is”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.
Who can use it
Section titled “Who can use it”- 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.
Where to find it
Section titled “Where to find it”In the app:
- Open the syndicate.
- Go to the Admin tab and tap Booking policy.
Route: /syndicates/:syndicateId/settings/booking-policy.
Fields / options
Section titled “Fields / options”The screen has two cards: Booking Policy and Maintenance Settings.
Booking Policy card
Section titled “Booking Policy card”| 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. Admin bookings skip the pending queue even when this is on. |
| Minimum booking duration (minutes) | 60 | Numeric. Blank falls back to the system default of 60. The validator rejects shorter time-slot bookings. |
| Max Advance Booking Days | 90 | Numeric. 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. |
Maintenance Settings card
Section titled “Maintenance Settings card”| 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. |
Settings are persisted on Save Policy.
Behaviour rules
Section titled “Behaviour rules”- Admin bookings are never held for approval. Even with the toggle on, only regular-member bookings enter the
pendingqueue. See Booking statuses. - 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 in its own billing screen.
- Squawk confirmation can be toggled at any time. Pending squawks from before the change keep their state; new squawks use the new rule.
See also
Section titled “See also”- Booking statuses — what
pending/confirmed/rejectedmean. - Tentative bookings — how pencilled-in bookings interact with approval.
- Squawk statuses — how admin confirmation affects the squawk lifecycle.
- Default and per-asset settings — the cascade for Max Advance Booking Days.