Policy Hierarchy

Rahal uses a three-level hierarchy to determine which policy applies to a user. This allows companies to set defaults while providing exceptions for specific roles or individuals.

The Three Levels

┌─────────────────────────────────┐
│   1. User-Specific Override     │  ← Highest priority
│   (Assigned directly to user)   │
│   (Supports time-bound dates)   │
└─────────────────────────────────┘
              ↓
┌─────────────────────────────────┐
│   2. Role-Based Policy          │
│   (Assigned to MEMBER/MANAGER/  │
│    ADMIN or custom role)        │
│   (User must be active)         │
└─────────────────────────────────┘
              ↓
┌─────────────────────────────────┐
│   3. Company Default Policy     │  ← Lowest priority (fallback)
│   (Applies to everyone else)    │
│   (Required - must exist)       │
└─────────────────────────────────┘

Resolution Algorithm

The backend resolves policies using this exact flow:

Only one policy applies at a time. Policies are not merged or combined. Resolution stops at the first valid match.

Examples

Example 1: Standard Employee

Setup:

Company default: "Standard Travel Policy" (Economy only, max $500)
Member role: No assignment
User: No assignment

Result: User gets "Standard Travel Policy"

Example 2: Manager with Role Policy

Setup:

Company default: "Standard Travel Policy"
Manager role: "Manager Travel Policy" (Premium Economy allowed, max $800)
User (Manager): No assignment

Result: User gets "Manager Travel Policy" (role-based)

Example 3: Executive with Override

Setup:

Company default: "Standard Travel Policy"
Admin role: "Admin Travel Policy"
User (Admin): "Executive Travel Policy" (Business class, max $2,000)

Result: User gets "Executive Travel Policy" (user-specific override)

Time-Bound Assignments

User-specific policies can have effective dates:

Effective From - Policy starts applying on this date (optional)
Effective Until - Policy stops applying after this date (optional)

Time Validation Rules

effectiveFrom	effectiveUntil	Behavior
null	null	Always valid
Set	null	Valid from date onwards
null	Set	Valid until date
Set	Set	Valid between dates

Validation logic:

If effectiveFrom is set and current time is before it → Policy not yet active
If effectiveUntil is set and current time is after it → Policy expired
If both pass (or are null) → Policy is valid

Use cases:

Temporary upgrade for a specific project
Trial period for new policy
Scheduled policy changes
Time-limited executive travel permissions

If a time-bound policy is not yet active or has expired, the system automatically falls back to the role policy or company default. No manual intervention needed.

Role-based policies and company default policies do not support time-bound assignments. They are always active once assigned.

Viewing Effective Policies

For Admins

In the dashboard, you can:

Go to Policies → Assignments
Use the Policy Preview feature to see which policy applies to any user
View the assignment source (User/Role/Default)

For Users

Users see their policy status when booking:

Policy compliance indicators in search results
Detailed policy information on the booking review page

Best Practices

Set a sensible company default - Most users should be covered by the default policy
Use role-based for common patterns - If all Managers need the same policy, assign to the role
Reserve user-specific for exceptions - Executives, frequent travelers, or special cases
Use time-bounds for temporary changes - Don't forget to set expiration dates

Policy Hierarchy

On this page