Feature Integration
How booking requests integrate with policies, budgets, and delegation
Feature Integration
Booking requests are deeply integrated with other Rahal features. Understanding these connections is essential for effective use of the platform.
Policy Integration
Evaluation at Submission
When a booking request is created:
-
Policy Resolution — System finds the user's effective policy
- User-specific policy (highest priority)
- Role-based policy
- Company default policy
-
Rule Matching — Each item is evaluated against policy rules
- Flight rules: routes, cabin class, budget tiers
- Hotel rules: locations, star ratings, price limits
-
Action Determination — Policy action is determined
- ALLOW → Direct booking (no request)
- WARN_AND_ALLOW → Direct booking with warning
- REQUIRE_APPROVAL → Request created
- BLOCK → Booking prevented
-
Violation Logging — All violations are recorded
- Stored in policy violation logs
- Associated with the booking request
- Visible to administrators
Policy Context in Requests
The request stores:
| Field | Description |
|---|---|
policyId | ID of the evaluated policy |
| Violations | Details of each rule violation |
| Action | The policy action that was applied |
This context helps admins understand why the request was created.
Example Flow
When a user selects a Baghdad → London flight in Business Class:
- The system matches against the "International flights" policy rule
- The rule only allows Economy class for this route
- A cabin class violation is detected
- Since the policy action is Require Approval, a booking request is created
- The violation is logged with the message "Business class not allowed"
Budget Integration
Budget Reservation Lifecycle
Budgets interact with booking requests through a reservation system:
Reservation Timing
When budget is reserved depends on company settings:
| Timing | When Reserved | Use Case |
|---|---|---|
ON_REQUEST | Request submission | Strict budget control |
ON_APPROVAL | Request completion | Flexible for pending requests |
ON_CONFIRMATION | Booking confirmation | Loosest control |
Budget Status Capture
At request creation, the system captures:
| Data | Description |
|---|---|
| Budget ID | Which budget was evaluated |
| Available Amount | How much was available |
| Requested Amount | Cost of the booking |
| Exceeded Amount | How much over budget (if any) |
| Currency | Budget currency (may differ from booking) |
| Enforcement Mode | How violations are handled |
Status Transitions and Budget
| Request Transition | Budget Action |
|---|---|
| Created (PENDING) | Reserve amount (if ON_REQUEST) |
| PENDING → COMPLETED | Confirm reservation (pending → spent) |
| PENDING → CANCELLED | Release reservation (pending → available) |
If a request stays PENDING for a long time with ON_REQUEST timing, the reserved budget is unavailable for other bookings. Review pending requests regularly.
Delegation Integration
Creating Requests for Others
Users with delegation access can create booking requests on behalf of other users. When User B (delegate) creates a request for User A's (delegator) travelers:
| Aspect | Value | Explanation |
|---|---|---|
| Request attributed to | User A | The booking is for User A |
| Created by | User B | Tracks who submitted the request |
| Policy evaluated for | User A | User A's policy rules apply |
| Budget checked for | User A | Consumes User A's budget |
Required Scope
To create booking requests for another user, the delegate needs:
| Scope | Description |
|---|---|
CREATE_BOOKINGS | Required for submitting requests |
Visible Information
| Data | Who Can See |
|---|---|
requestedBy | Who the booking is for |
createdBy | Who actually created it (if different) |
This distinction is important for:
- Audit trails
- Understanding request origin
- Permission checking for cancellation
Cancellation Rights
A request can be cancelled by:
- The requestedBy user (whose travel it is)
- The createdBy user (who submitted it)
- Any admin with appropriate permissions
Traveler Integration
Traveler Selection
When creating a request:
- User selects travelers from their available list
- This includes their own travelers + delegated travelers
- Each traveler is assigned a type code (ADT/CHD/INF)
Stored Traveler Data
Requests store:
| Field | Description |
|---|---|
| Traveler ID | Reference to traveler profile |
| Type Code | ADT, CHD, or INF |
| Profile Data | Name, contact info (at submission time) |
| Passport Info | Primary passport details |
Passport Requirements
For international travel, passport information is critical:
- Primary passport is automatically selected
- Passport must be valid for travel dates
- Expiry warnings are shown if applicable
Company Integration
Company Context
Every request is associated with a company:
| Field | Source |
|---|---|
companyId | From user's active company membership |
| Company Name | Displayed for admin context |
| Company Settings | Determines booking mode |
Data Flow Summary
Each booking request captures context from multiple sources:
| Source | Data Captured |
|---|---|
| Policy | Policy ID, violations, action taken, matched rules |
| Budget | Budget ID, reserved amount, available balance, currency |
| Travelers | Traveler profiles, passport details, type codes, count |
| Company | Company ID, booking mode settings |
This context enables administrators to make informed decisions when processing requests.