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.
| Scope | Use Case |
|---|---|
| Reservation | Guest information collected at check-in or booking |
| Identity | Personal information for member registration or renewal |
| Space | Inspection or report forms for rooms and equipment |
| Facility | Facility-wide configuration or application forms |
| Standalone | Survey or contact forms published via a public URL |
Feature 2: Creating a New Form
Click "New Form" to expand an inline creation form.
Input Fields
| Field | Description | Required |
|---|---|---|
| Form Name | Display name in the admin panel (e.g., Check-in Guest Form) | Yes |
| Description | Internal note on the form's purpose (not shown to guests) | No |
| Target Scope | Select from the 5 scopes above | Yes |
| Public URL Slug | Shown only when Standalone is selected. Use lowercase letters, numbers, and hyphens (e.g., customer-survey-2026) | Optional for standalone |
Steps
- Click "New Form"
- Enter a form name
- Optionally enter a description
- Select the target scope
- For standalone, enter a public URL slug
- Click "Create"
- 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
| Field | Description |
|---|---|
| Form Name | Display name in admin |
| Description | Internal memo |
| Status | Draft / Active / Archived |
| Target Scope | 5 scopes to choose from |
| Public URL Slug | Standalone only. Accessed at /form-demo?facility=…&slug=… |
| Reuse Policy | Controls pre-fill behavior (see below) |
| Reuse Scope | UnlockPass-wide / Organization / This Facility only |
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.
| Policy | Behavior | Typical Use Case |
|---|---|---|
| Every Visit (per_visit) | Guest re-enters all fields on each new reservation. No pre-fill when scope is "This Facility only" | Legally required guest registries (e.g. Japanese ryokan law) |
| One-Time (one_time) | After the first submission, later reservations show a read-only preview (no edits allowed) | Initial membership registration |
| Periodic | Re-entry required on reservations after N days | Annual or periodic facility-use agreements |
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_timepolicy)
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):
| # | Field Name | Type | Initial State | Required | Display Condition |
|---|---|---|---|---|---|
| 1 | Full Name | Text | Enabled | Required | Always |
| 2 | Date of Birth | Date | Disabled | Optional | Always |
| 3 | Phone Number | Text | Enabled | Required | Always |
| 4 | Address | Text | Enabled | Required | Always |
| 5 | State / Province | Text | Disabled | Optional | Always |
| 6 | Postal Code | Text | Disabled | Optional | Always |
| 7 | Nationality | Select | Enabled | Required | Always |
| 8 | Passport Number | Text | Enabled | Required | When nationality is not the host country |
| 9 | Passport Photo | Image | Enabled | Required | When nationality is not the host country |
| 10 | ID Number | Text | Enabled | Required | When nationality is the host country |
| 11 | ID Document Photo | Image | Enabled | Required | When nationality is the host country |
"Contact" has been renamed to "Phone Number." The underlying
field_keyremainscontactfor backward compatibility.
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
| Input | Description | Required |
|---|---|---|
| Label (Japanese) | Japanese label shown to users | Yes |
| Label (English) | English label shown to users | No (falls back to Japanese) |
| Field ID | Internal system identifier | No (auto-generated) |
| Field Type | text / textarea / select / date / image | Yes |
Newly added custom fields are optional by default. Toggle "Required" to make them mandatory.
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.
| Type | Description | When the form appears |
|---|---|---|
| Plan | Attached to a specific pricing plan. Guests who book that plan see this form | At booking (Booking / Go app, just before payment) |
| Event | Attached to a specific event | At event sign-up |
| Standalone URL | Published as a public-access standalone form | On direct URL access (no login required) |
To add a binding, select the type, enter the plan or event UUID (if applicable), and click "Add".
Plan binding vs. default check-in configuration form:
- Plan binding → the form is shown to guests at booking time in the Booking or Go app.
- 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
- Create a form with the "Standalone (Public URL)" scope
- Set a public URL slug (e.g.,
satisfaction-survey-2026) - Set the form status to "Active"
- 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
- Main menu → select "Reservation Approvals"
- All pending reservations are listed
- Click "Approve" on a reservation card to confirm it
- Click "Reject" to show the rejection reason input
- 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.
| Legacy Guest Form tab | New Form Management (/forms) |
|
|---|---|---|
| Forms per facility | One only | Multiple |
| Scopes | Reservation only | Reservation, Identity, Space, Facility, Standalone |
| Per-plan switching | Not available | Attach a different form per plan |
| Public surveys | Not available | Accessible by URL via slug |
| Data migration | — | Automatic (migrated as Default Reservation Form) |
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.