Request Lifecycle

Every booking request follows a defined lifecycle from creation to completion. Understanding these states and transitions is essential for both users and administrators.

Status States

Booking requests have exactly three possible statuses:

PENDING

The initial state when a request is created. The request is awaiting review and action by an administrator.

Characteristics:

• Request can be viewed by the requester and admins
• Request can be modified by admins (add/edit/remove items)
• Request can be cancelled by the requester or admin
• Budget is reserved (if configured for ON_REQUEST timing)
• Policy violations are logged but not blocking

Who can act:

• Requester: View, cancel
• Admin: View, modify, complete, cancel

COMPLETED

The request has been approved and processed. This is a terminal state.

Characteristics:

• Request cannot be modified
• Budget reservation is confirmed (moved to spent)
• Travel items can now be booked/ticketed
• Request becomes part of historical records

Triggered by: Admin marking the request as complete

CANCELLED

The request has been rejected or withdrawn. This is a terminal state.

Characteristics:

• Request cannot be modified
• Budget reservation is released (if any)
• Travel items are not booked
• Request becomes part of historical records

Triggered by:

• Admin rejecting the request
• Requester cancelling their own request

State Transition Diagram

Valid Transitions

Lifecycle Events

On Request Creation (→ PENDING)

1. Request data is stored atomically
2. Policy evaluation is performed
3. Policy violations are logged (if any)
4. Budget evaluation is performed
5. Budget reservation is created (if ON_REQUEST timing)
6. Budget violations are logged (if exceeded)

On Completion (PENDING → COMPLETED)

1. Status is updated to COMPLETED
2. Budget reservation is confirmed (pending → spent)
3. Request becomes read-only
4. Booking can be processed by travel team

On Cancellation (PENDING → CANCELLED)

1. Status is updated to CANCELLED
2. Budget reservation is released
3. Request becomes read-only
4. No booking is made

Timing Considerations

How Long Can Requests Stay Pending?

There is no automatic timeout for pending requests. They remain pending until:

• An admin completes or cancels them
• The requester cancels them

Budget Reservation Duration

When budget is reserved ON_REQUEST:

• The reservation persists as long as the request is PENDING
• This reduces available budget for new bookings
• Long-pending requests can tie up budget unnecessarily

Audit Trail

Every status change is tracked:

• Timestamp of the change
• Who triggered the change
• Previous and new status

This creates an immutable history for compliance and dispute resolution.

Best Practices

For Administrators

1. Process requests promptly — Pending requests tie up budget and may become stale
2. Review before completing — Verify all items are correct before approval
3. Provide context when cancelling — Use notes to explain rejection reasons

For Users

1. Cancel promptly if plans change — This releases budget for other uses
2. Include clear notes — Help admins understand the request context
3. Check status regularly — Pending requests may need follow-up