Form Management Help

Overview

Form Management lets you create and manage all information-collection forms for your facility in one place. From guest check-in forms (a superset of the legacy Guest Form) to member registration, surveys, and facility inspections — you can run multiple forms per facility, each tailored to its use case.

What you can do on this page:

• View and filter all forms for a facility
• Create a new form (name, description, target scope, public URL slug)
• Click any form to open the form editor (fields and bindings)
• Manage form status (Draft / Active / Archived)

---

How to Access

Main menu → select "Forms".

---

Features

Feature 1: Form List and Filtering

All forms appear as cards showing the form name, scope badge, status badge, public slug (if set), and last updated date.

Scope Filter

Use the dropdown to narrow the list to a specific scope.

---

Feature 2: Creating a New Form

Click "New Form" to expand an inline creation form.

Input Fields

Steps

1. Click "New Form"
2. Enter a form name
3. Optionally enter a description
4. Select the target scope
5. For standalone, enter a public URL slug
6. Click "Create"
7. You are automatically taken to the form editor

---

Feature 3: Form Editor

Click any form card in the list to open the form editor. The editor has three sections.

3-1: Form Metadata

Click "Save" to confirm changes. Click "Delete" to remove the form (a confirmation dialog appears). System default forms ("Default Reservation Form", etc.) cannot be deleted.

A form is never asked twice within the same reservation

When a form is bound to a plan, the guest fills it in at booking time. If an answer is already recorded for that reservation, the form is not shown again at check-in for that same reservation. Booking and check-in are consecutive steps of the same stay, so — regardless of the reuse policy below (Every Visit / One-Time / Periodic) — the same guest is never asked to fill the form twice within one reservation.

Walk-in (direct check-in) or reservations where the form was not filled at booking still show the form at check-in, as before.

Reuse Policy (UnlockPass Pre-fill)

The reuse policy controls how a form is treated across separate reservations and future stays (the same-reservation no-repeat behavior above always applies, independent of this setting). When a guest has submitted this form on a previous reservation, their previous answers can be pre-filled on the next submission.

Setting the reuse scope to "UnlockPass-wide" allows answers submitted at other facilities to be used as pre-fill.

Guest-facing Confirm step:

When previous answers are available, the guest sees a read-only preview of their last submission with two buttons:

• "Submit as-is" — submits without changes
• "Edit" — returns to the input form to make changes (hidden for one_time policy)

3-2: Form Fields

All fields in the form are shown in a table.

Reservation-scope forms include the following 11 default fields (cannot be deleted):

"Contact" has been renamed to "Mobile Number" (previously renamed once already, from "Phone Number"). The underlying field_key remains contact for backward compatibility. The type has also been changed to the phone number type so it can support SMS verification — see SMS Phone Verification for details.

Fields with an initial state of "Disabled" (Date of Birth, State / Province, Postal Code) appear grayed out with a "Disabled" badge in the list. They can be enabled with a single tap. The Required toggle becomes available after enabling.

Other scopes have no default fields — add any custom fields you need.

Enabling and Disabling Default Fields

All default fields can be toggled on or off individually.

• Disabled fields are not shown to guests on the input form
• In the field list, disabled fields appear grayed out with a "Disabled" badge
• To enable a field, turn on its "Enabled" toggle (auto-saved immediately)
• The Required toggle can only be changed while the field is enabled
• Example: facilities that only host domestic guests can disable all nationality and passport fields

Reordering Fields

You can change the order in which fields appear on the form. Changes are saved immediately.

• Desktop: Drag the ⋮⋮ handle at the left of each row to a new position. The drop target is highlighted in the brand color
• Mobile: Use the ↑ / ↓ buttons on each card to move a field one position at a time
• Custom fields and default fields can be freely mixed in any order

Adding a Custom Field

Newly added custom fields are optional by default. Toggle "Required" to make them mandatory.

Configuring choices (dropdown)

Selecting select as the field type reveals a choices editor underneath. Whatever you enter there is what the guest sees in the dropdown.

• Use "+ Add choice" to add a row, ↑ / ↓ to reorder, × to remove. The dropdown follows this order
• A select cannot be saved with zero choices. An empty dropdown gives the guest nothing to pick, and a required one makes the whole form unsubmittable
• Two choices cannot share a stored value — the stored value is the answer, so duplicates are indistinguishable afterwards

To edit the choices of an existing field, click the "N choices" badge in the Type column of the field list; the same editor opens under that row. A field with no choices yet is flagged in red as "No choices", so a missing setup is visible at a glance.

Changing a stored value later does not rewrite answers already submitted — they keep the old value. To fix wording only, edit "Label (Japanese)" and leave the stored value alone.

SMS Verification (phone field confirmation)

Any phone-type row (the default "Mobile Number" field, or a custom field you create with the phone number type) shows an "SMS Verification" badge (toggle) next to the field name. Turning it ON means the guest must confirm that phone number with an SMS code before they can submit the form — whether the form is shown at booking time or at check-in time.

This toggle can only be operated on a row that meets both conditions:

• The field is marked "Required" (an optional field could be submitted blank, making verification meaningless)
• The facility has already configured an SMS sending source (if not, a banner and link appear above the field list)

See SMS Phone Verification for how this works end to end.

Default Pending Reservation Form

The pending reservation form — used when a plan requires manual approval before confirmation — is a slimmed-down version of the standard reservation form. It includes the following 8 fields and excludes the international identity fields:

Full Name / Date of Birth / Phone Number / Address / State & Province / Postal Code / ID Number / ID Document Photo

(Nationality, Passport Number, and Passport Photo are not included.)

Enabling/disabling, required toggling, and reordering work the same way as the standard form.

Auto-save

The following actions are saved to the server immediately — no "Save" button needed:

• Toggling a field on or off
• Toggling the Required setting
• Reordering fields (drag-and-drop or ↑↓ buttons)
• Adding or deleting a custom field

The "Save" button is only required for form metadata (name, description, status, scope, reuse policy, etc.).

3-3: Bindings

Bindings specify where a form is displayed.

To add a binding, select the type, enter the plan or event UUID (if applicable), and click "Add".

How the form is chosen

Form attachment points are spread across four screens. Which one actually applies is decided by where the reservation came from — exactly one match — falling back to the default check-in configuration when nothing is attached there.

The first matching row wins — bindings never stack. This is why non-default check-in configurations have no form picker: those reservations use the default configuration's form.

The fallback to the default has one exception. When a guest checks in from their own reservation while signed in to the Booking / Go app, a plan-booked reservation does not fall back to the default check-in configuration's form (by design: that guest sees only the form for the plan they chose). Host check-in URLs, kiosks, and integration/import reservations still fall back as usual.

When the form appears is decided by the form itself. A plan-bound form whose display timing is "at check-in" or "both" also appears at check-in. "At booking only" means it will not.

Within one reservation, a form already answered at booking is never shown again at check-in, regardless of the reuse policy.

Plan binding vs. default check-in configuration form:

• Plan binding → shown to guests who booked that plan. Whether it appears at booking, at check-in, or both is decided by the form's own display-timing setting.
• Default check-in configuration form → the form is shown to guests at check-in time via a host-shared check-in URL or kiosk.

A guest booking through the Booking app and checking in themselves will see only the plan-bound form (at booking). A guest who uses your check-in URL or kiosk will see the default check-in configuration form (at check-in). See Check-in Configuration help for the full path breakdown.

---

Feature 4: Public Surveys (Standalone)

Standalone-scope forms are accessible at a public URL without login.

Setup Steps

1. Create a form with the "Standalone (Public URL)" scope
2. Set a public URL slug (e.g., satisfaction-survey-2026)
3. Set the form status to "Active"
4. Share the following URL:

   /form-demo?facility=<facility-id>&slug=<slug>
   

Common Use Cases

• Satisfaction survey QR codes in the facility
• Post-event attendee feedback
• Facility tour or viewing request forms

---

Feature 5: Reservation Approval (Manual Approval Mode)

When a plan's approval_mode is set to manual, guest reservations enter pending_approval status and do not confirm until a facility owner approves them.

Approval Flow

Guest books → pending_approval
  ↓ Owner approves → confirmed
  ↓ Owner rejects → cancelled

Approval Steps

1. Main menu → select "Reservation Approvals"
2. All pending reservations are listed
3. Click "Approve" on a reservation card to confirm it
4. Click "Reject" to show the rejection reason input
5. Enter a reason and click "Confirm Rejection"

For more details, see Reservation Approvals.

---

Migrating from the legacy Guest Form tab

The "Guest Form" tab inside Reservation Management (previously at /booking?tab=guestForm) was removed on 2026-05-19.

Edits made via the legacy tab were automatically picked up as "Default Reservation Form" and are now edited from /forms. The same data continues to back the existing flows.

---

Frequently Asked Questions

Q: What happened to my existing Guest Form settings?

They were automatically migrated to "Default Reservation Form" in the new form management. All settings are preserved.

Q: Can I attach multiple forms to a single plan?

It is recommended to attach one form per plan. Priority behavior when multiple bindings exist is not yet defined.

Q: Where can I view standalone form responses?

Response viewing and CSV export are planned for a future release. Direct viewing from the admin panel is not yet available.

Q: Where did the legacy Guest Registry (宿泊者名簿) page go?

The legacy Guest Registry has been folded into Form Management. Open the Forms list, then open Form Responses Hub — the "Guest Registry" quick-access card filters responses from the Default Reservation Form, with the same date range filter and CSV export as before. Per-form response browsing is also available from the dropdown.

Q: What happens when I archive a form?

Archived forms remain in the list but stop appearing in their linked contexts. No data is deleted.

Q: Can I change whether default fields are required?

Yes. All 11 default fields in reservation-scope forms support toggling between required and optional. You can also enable or disable each field, and reorder them freely. Note that the Required toggle is only available when a field is enabled — enable it first if it is currently disabled.

Q: Will a guest be asked to re-enter a form at check-in if they already filled it in at booking?

No. When an answer is already recorded for the reservation, that form is not shown again at check-in for the same reservation. Booking and check-in are treated as consecutive steps of the same stay, so the guest is never asked to re-enter within one reservation regardless of the reuse policy. The form still appears at check-in for walk-ins (direct check-in) or for reservations where the form was not filled in at booking.

---

Related Pages

• Reservation Approvals
• Booking Dashboard
• Pricing Plan Configuration
• Check-in Configuration (form timing and path-specific settings)
• SMS Phone Verification (field-level setup)