General Policies

The General section defines core approval and companion travel settings that apply across all travel types. These rules control who can approve travel requests, how to manage companions, and how Juno determines the travel window each guest is allowed to book within.

Approval Policy

Controls who reviews and approves travel requests:

Invite Coordinator

The person who created the travel invitation reviews requests. This default works well when coordinators oversee specific events or departments.

Best for:

• Departmental travel management
• Event-specific coordinators
• Distributed approval workflows

Specified User

A designated organization member reviews all requests regardless of who created the invitation. This enables centralized control.

Best for:

• Centralized travel management
• Consistent approval standards
• Organizations with dedicated travel coordinators

Passive Approval Review Window

If passive approvals are enabled for your organization, each travel policy has a Review Window — how long requests under that policy stay in review. Set it from the policy’s Passive Approvals card in one of two ways:

• Organization default — The policy follows the organization-wide review window (currently 1 day). If the default changes, every policy using this option follows it automatically.
• Custom window — The policy is pinned to a fixed window between 1 hour and 30 days and does not change with the organization default.

Use a custom window when a policy’s review period must not move with the organization default; otherwise keep the default so the policy stays aligned with organization-wide changes.

Companion Policy

Manage additional travelers on the same trip. Companion policies help control costs while accommodating legitimate business needs.

Policy Types

Never

Companions are not allowed under any circumstances. This is the most restrictive option and ensures only the primary invitee travels.

Use cases:

• Cost-sensitive organizations
• Standard employee travel
• Training or conference attendance

Always

Allow up to a specified number of companions without additional approval. This provides flexibility when travelers need assistance or collaboration.

Configuration:

• Allowed Companion Count - Maximum number of companions (1-10)
• Coordinator Override - Whether coordinators can override companion limits

Use cases:

• Executive travel
• Disability accommodations
• Team collaboration requirements

With Conditions

Allow companions based on custom field conditions (e.g., executive level, event type, travel purpose) for nuanced control.

Configuration:

• Allowed Companion Count - Maximum number of companions (1-10)
• Coordinator Override - Whether coordinators can override companion limits
• Conditions - Custom field logic determining when companions are allowed

Use cases:

• Executive-only spouse travel
• International trip companions
• Incentive or celebration trips with significant others

Coordinator Override

When enabled, coordinators can override companion count limits case-by-case for exceptional circumstances while maintaining control.

Travel Window

The travel window is the range of dates Juno treats as in-policy for a guest’s trip — the arrival and departure dates their flights and hotel stay are expected to fall within. Anything a guest books outside this window requires approval. You choose how the window is calculated with the Calculation method setting.

Juno Calculated

Juno builds the smallest viable window around the event by comparing the event dates and times with real flight availability, so the guest arrives in time and departs shortly after the event ends. This is the default and works well for most organizations.

With this method, you can optionally allow shoulder nights — additional nights beyond the window that let a guest arrive early or stay late.

Shoulder Night Policy Types

Never

No additional nights are allowed. Travelers can only book flights and accommodations for the dates Juno calculates.

Best for:

• Strict cost control
• Short local trips
• Day meetings or conferences

Always

Up to a specified number of shoulder nights are always allowed without additional approval. This accommodates travel logistics and potential cost savings.

Configuration:

• Allowed Shoulder Night Count — Maximum additional nights
• Coordinator Override — Whether coordinators can override shoulder night limits

Best for:

• International travel (to reduce jet lag)
• Locations with limited flight schedules
• Opportunities for additional business meetings

With Conditions

Shoulder nights are allowed based on custom field conditions.

Configuration:

• Allowed Shoulder Night Count — Maximum additional nights
• Coordinator Override — Whether coordinators can override shoulder night limits
• Conditions — Custom field logic determining when shoulder nights are allowed

Best for:

• Different rules for domestic vs. international travel
• Executive travel flexibility
• Event-specific accommodations

When Coordinator Override is enabled, travel coordinators can adjust the shoulder night count for a specific guest — for example, to capture significant flight savings or accommodate an important business opportunity.

Custom Rules

Custom Rules let you define the covered window yourself instead of letting Juno size it. You build an ordered list of rules that Juno evaluates from top to bottom; the first rule whose condition matches sets the window for that trip. A required Otherwise rule at the bottom is the fallback used when no rule above it matches.

Each rule — including the fallback — specifies three things:

• Covered nights — How many hotel nights the window covers. Choose either:
  • One night per invite event day, optionally plus a fixed number of additional nights. The count scales with the length of the event.
  • A fixed night count, which acts as a minimum. Day-before arrival or day-after return may still require additional covered nights.
• Arrival at destination — Juno-calculated (Juno picks the latest arrival that still makes the event) or Day before event starts.
• Departure from destination — Earliest viable after event ends or Day after event ends.

Rules other than the fallback are matched by outbound flight duration — the typical flight time of the outbound trip to the destination (one-way), not the round-trip total. You set a comparator (less than, less than or equal to, greater than, greater than or equal to) and a threshold in minutes. This lets you cover longer outbound trips more generously; for example, add a day-before arrival once the outbound flight time exceeds a threshold. Reorder rules by dragging them, since the first match wins.

Split Payment Policy

Split payments allow guests to pay for portions of their hotel booking that exceed what your organization’s policy covers. When enabled, guests can choose to pay the difference themselves rather than requesting approval for out-of-policy bookings.

Policy Types

Never

Split payments are disabled. Guests cannot pay for policy violations themselves and must request approval for any out-of-policy hotel bookings.

Best for:

• Organizations that want full control over all hotel costs
• Situations where you prefer to review all policy exceptions
• When you want to discourage guests from selecting out-of-policy options

Always

Split payments are offered when guests select hotel options that exceed policy limits. Guests can choose to pay the difference or request approval.

Best for:

• Organizations that want to give guests flexibility
• Reducing approval workload for minor policy violations
• Allowing guests to personalize their travel experience

How Split Payments Work

Split payments apply to two scenarios:

Extra Nights (Shoulder Nights)

When a guest wants to stay beyond the organization’s covered period—arriving early or staying late—they pay the full nightly rate for the extra nights.

• Guest pays: 100% of extra nights (base rate + taxes/fees)
• Organization pays: $0 for nights outside the covered period

Example: Your policy covers 3 nights for an event. A guest arrives a day early. You pay for nights 2-4; the guest pays for night 1.

Room Upgrade (Out-of-Policy Rate)

When a guest selects a room that exceeds your maximum price per night, they pay the per-night difference between the room rate and your policy limit.

• Guest pays: The difference above your max rate (per night)
• Organization pays: Up to your policy maximum per night

Example: Your policy allows $150/night maximum. A guest selects a $200/night room. You pay $150/night; the guest pays $50/night.

Combined Scenarios

Both can occur on the same booking. For example, a guest might arrive early (paying full rate for the extra night) AND select an upgraded room (paying the rate difference for covered nights).

Requirements and Limitations

• USD only: Split payments are currently only available for hotel bookings in USD
• Organization responsibility: If a guest’s split payment fails to process, your organization is responsible for the remaining charges
• Automatic processing: Split payment charges and refunds are processed automatically—no coordinator action required

Configuration Best Practices

Approval Policy

1. Start with Invite Coordinator - Most organizations benefit from distributed approval
2. Use Specified User for Compliance - When consistent approval standards are critical
3. Ensure Backup Coverage - Designated approvers should have backup coverage

Companion Policy

1. Begin with “Never” - Establish baseline cost control
2. Use Conditions for Flexibility - Allow companions based on role or trip type
3. Monitor Utilization - Track companion usage to optimize policies