Guest onboardings

Overview

Guest onboarding in Mallard Bay is how you collect structured information from guests after they book—intake questions, uploads, acknowledgements, and signatures—so trips stay organized and compliant. In the admin dashboard, that workflow is built around Forms: reusable questionnaires you create once, then attach to the right listings and pricing packages. When a booking matches those choices, guests get the applicable forms (for example from their trip details), complete them, and your team can review answers next to the booking.

Where to work in the dashboard (verified in this codebase): Open Forms at /forms. The Forms area is gated behind the Forms & Waivers capability (FormsAndWaivers).

Do not confuse this with /onboardings: In this repository, /onboardings is an internal outfitter subscription onboarding surface (new businesses joining Mallard Bay—tiers, payment links, onboarding status). It is not where you configure guest trip paperwork. Some internal documentation may label a feature “guest onboardings” beside that URL; for outfitters running trips, the correct place to configure guest packets is Forms (/forms). Why this matters: avoids sending team members to the wrong screen when guests still owe paperwork.

Prerequisites

• Forms & Waivers enabled on your account (Forms routes are wrapped in a paywall in the app).
• Listings and, when needed, pricing packages set up if you want forms to attach automatically to specific trips.
• If you use signature fields: the form must also include an email field marked required (the dashboard enforces this).

Exact sidebar placement of Forms is not defined in the navigation files searched for this article; you can go directly to /forms if needed.

Step-by-step: Configure guest-facing onboarding

1. Open Forms and start a form

Go to /forms. You’ll see a searchable list with name, number of inputs, submissions, whether the form is used for lead generation, and date added. Use Add New Form to start.

2. Basics: name, description, optional template

The create flow has two steps: Basics, then Form Details.

On Basics:

• Enter the name and optional description (description appears on the form’s details view).
• On new forms only (not when editing through this flow), you can pick an optional template to pre-populate fields.
• Choose Continue to create the draft and move on.

3. Form Details: attach the form to bookings

On Form Details, under Listings & Pricing Packages:

• Turn on the option described in-product as attaching the form to bookings (the UI stores listing and pricing package selections for link_to_booking_configs).
• With it on, select the listings and pricing packages this form applies to.

When attachment is enabled, two extra booking-related switches appear:

• Does each group member need to complete this form? — If off, only the host gets a submission; if on, each group member can complete their own (aligned with group bookings).
• Is this form required? — Per in-dashboard copy, required forms are shown as required on the client trip details (guest-facing trip experience is not implemented in this repo, but that is what the product copy states).

Saving Form Details runs an update and returns you to the forms list after success.

4. Optional: create leads from submissions

You can turn on automatic lead creation from each submission. Enabling it adds standard contact-style fields (first name, last name, email; phone optional) when those titles are not already present, so submissions map cleanly into leads.

5. Build custom fields

Under Custom Fields, add the inputs guests will see. Supported types in the API include text, textarea, email, phone, date, checkbox, selection, address, file upload, signature, name, and listing and pricing package selection.

Validation: If you add a signature field, you must also add an email field set to required, or the form will not save.

6. Form record: details, embed, submissions

Opening a form shows:

• Details — header info, embed instructions (JavaScript snippet), and (if configured) which listings and packages the form is tied to.
• Submissions — paginated submissions with a detail view for answers.

From the row actions you can view, edit, duplicate, copy link (uses form.url when the API provides it), share, or delete.

Embed code uses either the standard form script or the e-signature script when is_e_signature_required is true on the form. URLs are built from the environment’s Mallard Bay root URL and your form ID. Whether you can toggle “e-signature required” from this dashboard was not found in the form editor code reviewed here—the field exists on the model, but no obvious control appeared in the explored components.

7. Monitor completion on a booking

On booking details, when the booking exposes forms_with_submissions, a Forms section renders via shared BookingForms UI. It is only shown when there is at least one entry—if nothing appears, either no linked forms apply to that booking or no form instances exist yet.

Documents on the booking (for example liability PDFs from Outfitter documents) are separate UI from Forms. Both can be part of guest readiness but use different mechanisms.

Common pitfalls

• Wrong page: /onboardings is for outfitter subscription onboarding, not guest trip forms. Use /forms for guest packets.
• Signatures without email: You need a required email field when using signature inputs.
• Required / per-guest options missing: Those switches only appear after you enable Listings & Pricing Packages attachment.
• Detaching from listings: When attachment is off, the client omits link_to_booking_configs from the update if no listings or packages are selected—it does not always send an explicit “empty” config. Whether the server clears old listing links in that case is not confirmed from this frontend alone; after turning attachment off, confirm on the form Details view that links are gone.
• Copy link / share: Actions no-op if form.url is missing from the API.
• Feature access: Without Forms & Waivers, you will hit the paywall instead of the Forms UI.
• Publishing: The API includes is_published on forms, but no publish control showed up in the explored form screens—treat public/active behavior as partially unknown from this repo.

Related workflows

• Bookings — Forms tied to listings and packages surface on eligible bookings alongside payments, packages, guides, lodging, and remaining balances—useful when coordinating “paid and paperwork complete.”
• Leads — Optional lead creation connects standalone or embedded submissions to your lead pipeline.
• Waivers and static documents — Bookings can show waivers and outfitter documents separately from dynamic forms; use both when you need signed releases and structured questionnaires.
• Website — Embed snippets let guests complete forms on your site; share / copy link uses the hosted form URL when available.
• Listing & guest experience settings — Cross-cutting policies and documents you set at the outfitter level complement per-form questions on specific trips.

Not verified in this codebase: Whether automations or message templates send reminders specifically for incomplete forms or onboarding packets—confirm in your live account or backend documentation before promising that behavior to guests.