# Custom booking fields

# 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.


---
> Source: https://placeful-app.com/en/docs/bookings/custom-fields