Request Triggers
When and why booking requests are created instead of direct bookings
Request Triggers
Understanding when a booking request is created (vs. a direct booking) is crucial for both travelers and administrators. This page explains all the scenarios that trigger request creation.
Overview
Booking requests are created when a booking cannot proceed directly. Three main factors determine this:
Trigger 1: Policy Requires Approval
When a user's booking violates company policy and the policy action is REQUIRE_APPROVAL, a booking request is created.
How It Works
- User selects a flight or hotel
- System evaluates against user's effective policy
- If violations exist and action is REQUIRE_APPROVAL:
- Direct booking is blocked
- User is prompted to submit a request
- Request includes violation details for admin review
Example Scenarios
| Scenario | Policy Rule | Result |
|---|---|---|
| User books Business Class | Only Economy allowed | Request created |
| Flight costs 2,000 IQD | Max budget 1,500 IQD | Request created |
| User books 5-star hotel | Max 3-star allowed | Request created |
| User books London→Paris | Route not in approved list | Request created |
Policy Action Outcomes
| Policy Action | Direct Booking | Request Created |
|---|---|---|
| ALLOW | ✅ Yes | ❌ No |
| WARN_AND_ALLOW | ✅ Yes (with warning) | ❌ No |
| REQUIRE_APPROVAL | ❌ No | ✅ Yes |
| BLOCK | ❌ No | ❌ No (blocked entirely) |
When policy action is BLOCK, neither direct booking nor request submission is allowed. The user must choose a different option.
Trigger 2: Budget Exceeded
When a booking would exceed the user's available budget and the enforcement mode is REQUIRE_APPROVAL, a request is created.
How It Works
- User selects travel items
- System calculates total cost
- System checks user's budget:
- Available amount in current period
- Pending reservations (if any)
- If cost > available and enforcement is REQUIRE_APPROVAL:
- Request is created
- Budget evaluation details included
Budget Enforcement Modes
| Enforcement Mode | Budget Exceeded Behavior |
|---|---|
| TRACK_ONLY | Direct booking allowed (tracking only) |
| WARN | Direct booking allowed with warning |
| REQUIRE_APPROVAL | Request created |
| BLOCK | Booking blocked entirely |
Example Scenario
Consider a user with a monthly budget of 10,000 IQD. They have already spent 7,500 IQD and have 1,000 IQD pending in other requests, leaving 1,500 IQD available. When they attempt a booking costing 3,000 IQD:
- The booking exceeds available budget by 1,500 IQD
- If enforcement mode is Require Approval, a booking request is created
- The admin can then review and approve or reject the over-budget request
Trigger 3: Company Booking Mode
Companies can configure their booking mode to always require requests, regardless of policy or budget status.
Booking Modes
| Mode | Description | Request Required? |
|---|---|---|
| DIRECT_BOOKING | Users can book directly when in-policy | Only when policy/budget requires |
| REQUEST_ONLY | All bookings go through requests | ✅ Always |
| HYBRID | Direct for in-policy, request for violations | When out-of-policy |
REQUEST_ONLY Mode
When a company uses REQUEST_ONLY mode:
- Every booking submission creates a request
- Even fully compliant bookings require approval
- Gives travel admins full control over all travel
REQUEST_ONLY mode significantly increases admin workload. Use only when business processes require manual approval of all travel.
HYBRID Mode
HYBRID mode provides flexibility:
- In-policy bookings proceed directly
- Out-of-policy bookings create requests
- Balances traveler convenience with policy compliance
Combined Triggers
Multiple triggers can apply simultaneously. For example, a booking might violate cabin class policy (Require Approval) while also exceeding the user's budget (also Require Approval). In this case, the request includes context from all factors:
- Policy violations are logged and visible to admin
- Budget status is evaluated and stored
- Admin sees complete picture when processing
Request Context
When a request is created, it captures:
| Context | Description |
|---|---|
| Policy ID | Which policy was evaluated |
| Policy Violations | Specific rules violated |
| Budget Status | Available vs. requested amount |
| Original Pricing | Prices at time of request |
| Traveler Info | Who will be traveling |
This context helps administrators make informed decisions.
Special Cases
Delegation
When User B (delegate) creates a booking on behalf of User A (delegator):
| Aspect | Evaluated For | Explanation |
|---|---|---|
| Policy | User A | The booking is for User A, so their policy applies |
| Budget | User A | Consumes User A's budget, not the delegate's |
| Attribution | User A | requestedByUserId is User A |
| Creator tracking | User B | createdByUserId tracks who submitted |
This ensures the booking follows the traveler's rules, not the booker's.
Delegation requires the CREATE_BOOKINGS scope. The delegate must have explicit permission from the delegator.
Multiple Travelers
When booking for multiple travelers:
- Policy is evaluated once for the primary requesting user
- All travelers are included in the single request
- Admin reviews the complete traveler list
Multi-Service Requests
Requests containing both flights and hotels:
- Each item is evaluated independently
- If any item requires approval, request is created
- All items are bundled in the same request