Delegation Model
Understanding how user delegation relationships work in Rahal
Delegation Model
This page explains the core concepts behind Rahal's delegation system and how delegation relationships are structured.
Core Concepts
Delegator and Delegate
A delegation relationship always involves two parties:
| Role | Description | Example |
|---|---|---|
| Delegator | The user who owns the travelers and grants access to another user | An executive who wants their assistant to book travel |
| Delegate | The user who receives access and can act on behalf of the delegator | An executive assistant who books travel for their boss |
Direction of Access
The delegation direction determines who can access whose data:
- A delegates to B means B can access A's travelers
- B does NOT get access to make A view B's travelers
This is a one-way relationship. If two users need to access each other's travelers, two separate delegations must be created.
Delegation Properties
Each delegation record contains the following properties:
| Property | Description |
|---|---|
| Delegator User ID | The user granting access (owner of travelers) |
| Delegated User ID | The user receiving access |
| Company ID | The company context for this delegation |
| Scopes | Array of permission scopes granted |
| Is Active | Whether the delegation is currently active |
| Created At | When the delegation was created |
| Updated At | When the delegation was last modified |
Company Scope Requirement
Both users must be active members of the same company for a delegation to work.
Delegations are always scoped to a specific company. This means:
- Both the delegator and delegate must belong to the same company
- Both users must have an active company membership
- The delegation only applies within that company context
Relationship Uniqueness
The combination of delegator, delegate, and company must be unique. You cannot create duplicate delegations for the same user pair in the same company.
If you need to modify an existing delegation (e.g., add or remove scopes), you must update the existing delegation rather than creating a new one.
Active vs Inactive Delegations
Delegations can be temporarily disabled without being deleted:
| State | Effect |
|---|---|
| Active | Delegate can access delegator's travelers and perform granted actions |
| Inactive | Delegation exists but is not enforced; delegate cannot access delegator's data |
This allows administrators to temporarily suspend delegation access without losing the delegation configuration.
Traveler Access
When a delegation is active, the delegate gains access to all travelers owned by the delegator. There is no partial traveler access - it's all or nothing.
The specific actions the delegate can perform depend on the granted scopes.
Policy and Budget Attribution
When a delegate creates a booking for a delegator's travelers:
Key points:
- The delegator's policy is used for compliance evaluation
- The delegator's budget is consumed
- The booking appears in the delegator's booking history
- Reports and analytics attribute the booking to the delegator
This ensures that travel policies are enforced correctly based on the actual traveler's role, not the person making the booking.
Delegation Lifecycle
| Action | Result |
|---|---|
| Create | New delegation is created in active state |
| Deactivate | Delegation is paused but preserved |
| Reactivate | Delegation is resumed |
| Revoke/Delete | Delegation is permanently removed |
Related Concepts
- Scopes - Understanding delegation permissions
- Booking Flow - How delegation affects the booking process