Custom booking fields

Ask bookers for anything the built-in form does not cover — dietary requirements, company name, arrival notes — by attaching custom fields to an event or an area. Answers are stored on the booking and visible to staff on the booking detail.

Where fields are defined

• Event editor → Custom fields — applies to every booking of that event.
• Area editor → Custom fields — applies to no-event area bookings of that area.

Each field has a label, a technical key, a type, an optional placeholder, and a sort order.

Field types

Type	Input rendered
text	single-line text (max 255 chars)
textarea	multi-line text (max 5000 chars)
select	dropdown — requires one option label per row
checkbox	yes/no toggle (accepted/not accepted)
date	date picker (YYYY-MM-DD)
number	numeric input (integers or decimals)

When the field is asked

Every field has a collection phase:

• Booking — asked on the public confirm page, inside the booking flow. Booking-phase fields can be marked required: the customer cannot confirm without answering.
• Post-booking — asked after the booking is confirmed (confirmation page and follow-up). Post-booking fields are always optional — they can never block a booking.

Answers

Answers are stored on the booking's detail revision as {key: {label, value}} — editing or deleting a field does not erase already-collected answers, and the revision history keeps earlier values. Staff see answers on the booking detail; they are also part of booking exports.

Limits and rules

• Fields are per-bookable: duplicating an event does not imply duplicating its fields — recreate them on the new event or area.
• select fields need at least one option; empty option lists are rejected.
• Keep keys stable: the key is the storage identifier, so renaming it starts a new answer stream.