Concepts
Core concepts behind booking requests in Rahal
Booking Request Concepts
Understanding how booking requests work requires familiarity with several interconnected concepts. This section explains the fundamentals that underpin the entire booking request workflow.
Core Concepts
Request vs. Booking
It's important to distinguish between a booking request and an actual booking:
| Aspect | Booking Request | Confirmed Booking |
|---|---|---|
| Status | Pending approval | Completed transaction |
| Modifiable | Yes, by admin | Limited modifications |
| Reversible | Can be cancelled | May require refund process |
| Budget Impact | Reserved (pending) | Consumed (spent) |
| Travelers | Listed | Ticketed/confirmed |
A booking request is essentially a "draft" that must be approved before becoming an actual reservation.
Service Types
Booking requests can contain two types of travel services:
| Service | Description | Key Information |
|---|---|---|
| Flights | Air travel segments | Route, dates, times, airline, cabin class |
| Hotels | Accommodation | Hotel, location, dates, rooms, board basis |
A single request can contain:
- Multiple flights (e.g., outbound + return)
- Multiple hotels (e.g., multi-city trip)
- Both flights and hotels together
Traveler Types
Travelers attached to requests are categorized by age:
| Code | Type | Description |
|---|---|---|
ADT | Adult | 12+ years old |
CHD | Child | 2-11 years old |
INF | Infant | Under 2 years old |
These codes affect pricing and are validated against traveler birthdates.
Concept Deep Dives
Request Lifecycle
Status transitions and what each state means
Request Triggers
When and why booking requests are created
Feature Integration
How requests integrate with policies, budgets, and delegation
Key Principles
1. Atomic Transactions
When a booking request is created, all items (flights, hotels, travelers) are stored together in a single atomic transaction. This ensures data consistency—you'll never have a partial request.
2. Immutability of Terminal States
Once a request reaches COMPLETED or CANCELLED, it cannot be modified. This provides a clear audit trail and prevents confusion about what was actually approved.
3. Budget Reservation Lifecycle
Budget amounts are reserved when a request is created (if configured) and either:
- Confirmed (moved from pending to spent) when COMPLETED
- Released (returned to available) when CANCELLED
This prevents users from over-spending their budgets while requests are pending.
4. Policy Logging
Even when a request is allowed through REQUIRE_APPROVAL, any policy violations are logged. This provides visibility into travel patterns and policy compliance for reporting purposes.
Terminology Quick Reference
| Term | Definition |
|---|---|
| Booking Request | A pending travel request awaiting approval |
| Request Item | A flight or hotel within a request |
| Requester | The user who submitted the request |
| Creator | The user who created the request (may differ if delegating) |
| Service Type | Either "flights" or "hotels" |
| Terminal State | COMPLETED or CANCELLED (cannot change) |
| Pending Reservation | Budget amount held but not yet spent |