Custom Fields & Reporting

Custom fields let you collect organization-specific information from travelers beyond standard travel details. Use this data for reporting, compliance, and policy enforcement.

Field Types Available

Standard Field Types

Setting Up Custom Fields

Access Custom Fields

1. Go to Settings in your admin dashboard
2. Select Custom Fields from the menu

Creating a New Field

Click “Add Field” and configure:

Basic Information

• Name: The label users will see (e.g., “Department”, “Employee ID”)
• Description: Optional explanation of what the field is for

Collection Settings

When should this field be collected?

• Invitation: Coordinator fills this out when inviting travelers
• Onboarding: Traveler fills this out when they first sign in

How often should this field be collected?

• Once per invite: Field is specific to each invitation
• Once per user: Field is stored on the traveler’s profile

When should this field be shown?

• Always: Field appears for all travelers
• Conditionally: Field only appears when certain conditions are met

Required

• Turn on Required when the field must be completed before the form can be submitted
• Leave Required off to let the form be submitted without a value
• Who has to complete it follows the entry point above: coordinators complete Invitation fields on the invite form, travelers complete Onboarding fields themselves
• Requiredness and visibility are independent, so a conditionally shown field can be either required or optional

Include in webhooks

• Available on fields collected for Every invite, including connected Ramp fields: open the field under Ramp custom fields to turn it on. A Ramp field must be added to Juno before the setting is available
• Turn it on to send the field’s answer with every invite and booking webhook event, so a connected system can match each event to its own record (for example, a request or reference ID your system sent when creating the invite)
• Leave it off, the default, for anything your integrations don’t need
• The setting is read when each event is created, so turning it on or off applies to new events right away, including events for existing invites. Events created before the change keep the answers they were created with, so pending deliveries and retries can still include an answer after you turn the setting off
• The setting doesn’t apply to transaction webhooks (transaction.recorded and transaction.customer_charge_confirmed), which include every custom field answer on the transaction, as the transactions report does

Field Configuration

For Boolean: No option list is needed. Choose True or False; leaving an optional field blank does not set it to False. Juno accepts either capitalization in bulk and event CSV files.

For Single Select and Multi-Select:

1. Click Add option to create choices
2. Set the Name, which is the label coordinators and travelers see
3. Set the Value Juno records for policies, reports, and exports. It defaults to the Name, but you can use a different reporting value
4. Optionally set an External ID when an integration needs to reference the option through the Developer API

You can add options individually or import them from a CSV file. CSV templates, imports, and exports include separate Name, Value, and External ID columns.

For File Upload:

• Supports common file formats: images (PNG, JPEG, WebP, GIF), documents (PDF, Word, Excel), text files, and archives
• Maximum file size: 25MB
• Files are securely stored and accessible via signed URLs
• Previously uploaded files can be viewed and replaced

Field External ID: Optional identifier for integrations that need to reference the custom field itself

Managing Existing Fields

Preventing Duplicate Invites

From Settings > Custom Fields, use Duplicate invite prevention to select the identity fields Juno should use when checking invites. You can select text and single-select invitation fields that are shown on every invite, including Ramp accounting fields that are entered on the invite. Fields with visibility conditions, and Ramp fields that are hidden or filled in automatically (such as the invite dates or invite ID), can’t be selected, because some invites couldn’t fill them in. Juno treats an invite as a duplicate when its selected field values and local start and end dates match an existing active invite.

Juno checks for duplicates when you create an invite and when you edit an invite’s dates or selected identity-field values. An edit is blocked if it would create a duplicate.

Drafts reserve the same identity as submitted invites. When duplicate prevention is configured, every new draft must include a value for each selected identity field. Saving a draft cannot remove one of those values while the draft is active.

Sandbox, canceled, withdrawn, archived, and completed or past invites do not block a new or updated invite. If active duplicates already exist, resolve them before enabling or changing the rule.

Add-ons

The Add-ons section of Settings > Custom Fields holds optional features that build on your invite fields.

Billing instructions

Organizations connected to Ramp can let coordinators and approvers write free-text billing instructions on each invite, per travel type, describing how a trip’s charges should be billed or split. The visibility rule uses the same condition builder as conditional custom fields, so you can limit the card to invites whose field values match. See Billing Instructions for enabling the add-on and how instructions flow through drafts, trip exceptions, and approvals.

Using Custom Fields in Forms

Once configured, custom fields appear in the appropriate forms:

• Invitation fields show up when coordinators create invitations
• Onboarding fields appear when travelers first sign in
• Conditional fields only display when their conditions are met

Connected Ramp accounting fields

When a connected single-select Ramp accounting field is eligible for collection on an invitation and has a configured default, Juno pre-fills that option on the coordinator’s invite form if no answer already exists. Review the prefilled answer before sending the invite. Leave it selected to submit the default, or choose another available option to submit your selection instead. An answer you have already entered or previously saved takes precedence over the default.

When your organization connects Ramp accounting fields, Juno uses the answers collected on the invitation or traveler profile to code cleared Ramp transactions. Connected Ramp Boolean fields appear as a choice on invitation forms. Choose true or false to send a value; leaving one unanswered does not mean false. Juno fills only empty Ramp fields: it never overwrites an existing Ramp value or changes a transaction that is ready or synced.

Event Guest Invite Types

The official invite-type field includes a protected Event option. Event guests receive this type automatically by default, without coordinator input.

With Automatic, the Event option is hidden from the customer option editor, but remains available in insights and volume estimates. With Coordinator choice, you can edit its name and reporting value like other options, for example renaming it to Event guest. It retains its Event designation and existing references, and cannot be deleted. Editing a reporting value changes what reports and exports display, so coordinate changes with integration owners.

If your organization uses Coordinator choice and has other invite types, select a type for each event guest before sending invitations. A blank field does not automatically select Event. An explicitly configured group default can supply the selection. When Event is the only available type, Juno assigns it automatically without showing a selector.

Regular guest invitations use your customer-defined types, not Event. If you have just one customer type, such as Candidate, Juno selects it automatically. Configure at least one customer type before creating regular invitations. Event-only organizations can continue sending event invitations without adding a type they do not need.

Juno support can change this setting. It is separate from access to the Events product, and changing it does not rewrite existing invite classifications.

Setting Up Conditional Fields

For fields set to show “Conditionally,” define when they appear:

1. Select the custom field that should trigger the condition
2. Choose the condition (equals, not equals, contains, etc.)
3. Set the value that triggers the field to show
4. Save the condition

Example: Show “Medical License Number” only when “Professional Type” equals “Physician”

Using Fields in Policies

Custom field values can drive policy decisions:

1. When creating or editing policies, custom fields appear as condition options
2. Select the custom field you want to use
3. Set the condition logic (equals, greater than, etc.)
4. Define what happens when the condition is met

Example: Apply different expense limits based on department or role.

Reporting with Custom Fields

Custom field data appears in:

• Trip reports - All custom field values included
• Expense reports - Fields associated with travelers and invitations
• Reconciliation reports - For booking transactions to your financial system

Coordinators can also search the Invites page and event guest tables by invitation custom-field answers, such as a case number or a selected option’s name. Search covers fields collected on the invitation, whether answered per invite or per user. It doesn’t include onboarding or approval fields, or removed fields and answers. See Searching invites.

Filtering approvals

In the unified Approvals dashboard, use Add filter and choose an invitation custom field to narrow approvals by its answers:

• For single-select, multi-select, and nested fields, select one or more options.
• For Boolean fields, select True or False. An unanswered field does not match False.
• For text and validated text, enter part of the answer in Contains. Matching ignores capitalization.
• For file uploads, Contains matches the stored file reference, not the document’s contents.

Multiple field filters must all match. Within one field, any selected option can match. You can remove filters individually or use Clear all. Selecting a saved view also clears custom-field filters. Filtering does not change which approvals you have permission to see.

Best Practices

Field Design

• Keep names clear and concise - Users should immediately understand what to enter
• Use descriptions sparingly - Only when the field name isn’t self-explanatory
• Limit required fields - Only make fields required if the information is essential

Data Quality

• Prefer dropdowns - Reduces errors and inconsistencies
• Provide examples - Show format for fields like employee IDs
• Test with real users - Ensure fields make sense to actual travelers

Troubleshooting

Common Issues

Field not appearing in forms

• Check that it’s enabled and not set to conditional
• Verify the entry point matches where you expect to see it
• Ensure any conditional logic is set up correctly

Data not appearing in reports

• Ensure the field was collected before the trips you’re reporting on
• Check that the field is marked as active
• Verify report date ranges include when the data was collected

For assistance with custom field setup or troubleshooting, contact your account manager or use Scout AI support in your dashboard.