Guest Data & Privacy

Juno collects guest data so guests can book compliant travel, submit expenses, receive reimbursements, and get support. The platform is designed around scoped access: guests manage their own information, coordinators see the trips and guests they are responsible for, and admins control organization-wide configuration.

This page summarizes the kinds of guest data Juno handles and the safeguards Juno uses to protect guest privacy.

What Guest Data Juno Handles

Juno may handle the following types of guest data depending on which products your organization uses:

How Access Is Limited

Juno limits guest data access through several layers that work together: authenticated sessions, organization boundaries, role-based permissions, relationship checks, read-only grants, and workflow-specific file access gates.

Authentication is required

Guests, coordinators, admins, and service users must be authenticated before accessing guest data. Organization users can use SSO or code-based authentication, depending on your setup. Guests use code-based authentication to access their own travel and expense experience.

Juno ties each authenticated session to an organization context. That context is used throughout the product to decide which organization’s guests, trips, reports, payment methods, and configuration a user can access.

Organization boundaries are enforced

Guest records are scoped to the organization that created or manages the invite. Before Juno returns invite, trip, booking, traveler profile, report, payment, or custom-field data, the system checks that the requesting user is operating in the same organization or has an approved service-level role.

This prevents a coordinator, admin, or guest from accessing records that belong to another customer organization simply by knowing an invite, profile, booking, or file identifier.

Guests manage their own data

Guests can access their own invite, trip, traveler profile, booking, expense, and reimbursement information. Traveler profiles are tied to the guest’s Juno account, and guests can save details for future bookings.

When a guest views or updates an invite, Juno checks that the invite is associated with that guest. When a guest manages a traveler profile, Juno checks that the profile belongs to that guest’s Juno account.

Coordinators see relevant guests and trips

Coordinators can access guest data when they are responsible for that guest or have the right organization-level permissions. Juno checks both the user’s organization and their relationship to the invite before returning invite, trip, booking, or traveler profile data.

Common ways a coordinator can receive access include being the inviter for a guest, having trip oversight permissions, being assigned as an event manager, or receiving an invite-specific view grant. These checks are applied at the invite and booking level, not only at the page level.

For traveler profiles, coordinators can access another user’s profile only when the user is in the same organization and the coordinator has the appropriate travel-management access. This supports booking-on-behalf workflows without making every guest profile broadly visible by default.

Read-only access stays read-only

For event workflows, Juno also supports event managers and invite-specific view grants. View grants are read-only — a user with view-only access can see the invite they were granted access to, but cannot act on it.

Juno separates read access from mutation access. A user who can view a guest record does not automatically have permission to edit the invite, send messages, create bookings, generate vouchers, withdraw an invite, or otherwise take action on the guest’s trip.

Admins control organization-wide access

Admins can configure access using Juno’s role-based access controls and SSO setup. Permissions such as trip oversight, travel management, reporting, payment management, and user administration determine which organization users can access broad guest data surfaces.

Admins should treat reporting, trip oversight, payment management, and user administration as elevated permissions because these roles can expose broader sets of guest data than a single invite or trip. Juno supports least-privilege access by separating these permissions instead of granting every coordinator full admin visibility.

Files require scoped signed access

Uploaded files, such as custom-field files and receipts, are not exposed as public links in the product. For custom-field files, Juno stores a file reference and returns a signed download URL only after confirming that the authenticated user belongs to the organization associated with the file.

This means file access depends on both authentication and organization scope. Users cannot open an uploaded custom-field file unless Juno first authorizes the request.

Service access is limited to operational needs

Some Juno service users and support workflows need access to guest data to operate the platform, troubleshoot bookings, provide guest support, process payments, or coordinate with travel providers. These service-level access paths are separate from ordinary coordinator and guest access and are used for operational workflows rather than customer-wide self-service visibility.

See SSO & Access Control for more on authentication and role management.

Safeguards by Workflow

Event address privacy

Some organizations give guests a separate check-in location and don’t want the real event address shared in advance. When event address privacy is enabled for your organization, guest-facing surfaces show the venue name, city, and a venue-area map pin, but not the street address. This applies everywhere a guest sees the event, including the guest app, emails, calendar attachments, texts, and AI assistants.

Coordinators and admins see the complete event location for the invites they manage, so they can review and edit event details. The exception is an invite where the coordinator is themselves the guest: Juno treats them as that trip’s guest, so the street address is hidden from them for that invite.

This setting is enabled by Juno for your organization on request rather than from your admin settings.

Traveler profiles

Traveler profiles are used for booking and are tied to the guest’s Juno account. A guest can access their own profile, while coordinators can only access another user’s traveler profile when they are in the same organization and have coordinator-level access.

When a coordinator books on behalf of a guest, they can request traveler details from the guest instead of collecting the information manually. See Requesting Traveler Details for the guest-facing flow.

Custom fields and file uploads

Custom fields are configured by your organization, so admins decide what additional data is collected and where it appears. Fields can be collected per invite or per user profile, and conditional fields can limit collection to the guests who match your rules.

File-upload custom fields are stored as file references. When a user opens a file, Juno checks that the user belongs to the organization associated with that file before returning a signed download URL.

See Custom Fields & Reporting for configuration guidance.

Reports and exports

Reports may include guest invite data, custom field values, booking details, expenses, and reimbursement information. Access to reporting is permissioned, and report views stay scoped to the organization and the trips the user is allowed to view.

Because CSV exports can include all matching rows and visible custom field columns, admins should limit reporting permissions to users who need that data for their role.

Scout AI support

Scout, Juno’s AI assistant, uses Juno product documentation and any published knowledge articles your organization creates. For manual knowledge articles, admins decide whether Scout can use the article for All Guests or only for Certain Guests who match selected guest attributes.

Draft knowledge articles are not used by Scout until they are published. See Scout Knowledge Sources for details.

Travel and payment providers

Some guest data must be shared with external providers to complete a workflow. For example, airlines, hotels, rail providers, rental car suppliers, ground transportation providers, payment processors, payout providers, and support systems may receive the information required to book travel, process payment, reimburse expenses, or provide support.

Juno sends provider-specific data for the related workflow rather than exposing broad guest records to every provider.

Privacy Practices for Admins

Use these practices to reduce unnecessary access to guest data:

1. Grant broad reporting and trip oversight permissions only to users who need them.
2. Use custom fields only for information that supports a clear business, policy, reporting, or compliance need.
3. Prefer dropdown custom fields over free-text fields when possible to reduce accidental sensitive entries.
4. Review custom field visibility and conditional rules before inviting guests at scale.
5. Keep Scout knowledge articles focused on guidance guests should receive, and use Certain Guests visibility when an answer applies only to a subset of guests.
6. Review coordinator and admin access when team responsibilities change.

Customer Questions

If a customer asks what safeguards protect guest privacy, the short answer is:

Juno limits guest data access through authenticated sessions, organization boundaries, role-based permissions, invite-level relationship checks, traveler-profile ownership checks, read-only view grants, separate write-access checks, and signed access to uploaded custom-field files. Admins control what extra guest data is collected through custom fields and which guest attributes Scout can use when answering questions from organization-managed knowledge articles.