Booking form reference
The screen that decides what people are asked when they book — every built-in field you can switch off or rename, every setting on a field you add yourself, and which form a given booking ends up using.
A booking form is the set of questions somebody answers while they book. You compose it: start from the built-in fields, switch off the ones your organisation never asks, drag the rest into the order you want, rename the ones whose wording does not fit, and add fields of your own.
Drop the fields you do not ask for, move the ones that matter to the top, and add your own.
A form is assigned to resources, and a site can have as many forms as it has kinds of space. To build one, see Ask for a cost item and project ID on every booking.
Open Booking formThe form itself
| Setting | What it does | When to change it |
|---|---|---|
| Name | Names the form in the list and on each resource that uses it | Name it after the group of resources it serves, not after its fields — the fields change, the group does not |
| Branch management | Limits the form to one branch of the organisation | Only on a multi-branch site where each branch runs its own forms |
| Default display form | Makes this the form people see before they have picked a resource | Turn on for the one form whose questions apply almost everywhere. At most one form per site can hold it |
Below those sits the field list itself: every built-in field and every field you have added, in the order they appear on the booking form. Drag to reorder, select a field to configure it, and choose Add field for one of your own.
Built-in fields
These exist on every form. Some can only be reordered; the rest open a small editor when selected.
| Field | What you can change | Notes |
|---|---|---|
| Booking purpose | Order only | Appears only when the resource has booking purposes |
| Title | Visibility per resource kind, Allow private booking, and its own name | The subject of the booking |
| Period | Order only | |
| Resources | Order only | |
| Number of room users | Show manual participant count | Appears only when the resource is a room |
| Online meeting | Visibility per resource kind | |
| Service | Order only | Appears only where booking services exist |
| Organizer | Order only | Appears only where a delegated user exists |
| Attendee | Visibility per resource kind and an Alias name | |
| Host | Its own name only | Shown only when the resource policy allows inviting a host, which is why it has no visibility switches of its own |
| Visiting purpose | Order only | Appears only with visitor management |
| Notes | Visibility per resource kind and its own name | The free-text body of the booking |
Visibility per resource kind means Show when room booking and Show when other booking. Desk, equipment and parking space appear in the list but are fixed off for Title and Attendee — those two questions only make sense for a room or an “other” resource.
Allow private booking, on Title, lets the person hide the subject and attendees from everyone else on the resource calendar, the booking panel and signage.
The Title field: where it appears, and whether a booking may be private.
Alias name and Customize field name do the same job under two labels — they replace the wording of a built-in field without changing what it does. Use them where your organisation’s word differs from ours: Guests rather than Attendee, Agenda rather than Notes.
Fields you add yourself
Every field you add carries the same settings.
| Setting | What it does | When to change it |
|---|---|---|
| Name | What the person booking sees | Always fill it in for every language your site uses — a name given only in English renders in English on a Japanese screen |
| Description | A one-line hint under the field | Use it for the rule people get wrong, not to restate the name |
| Icon | The mark beside the field | Pick something recognisable; it is how people find the field in a long form |
| Field type | What kind of answer is accepted — see the table below | |
| Select option | The choices, for Select and Multiple select | For a short fixed list. A long or shared list belongs in a data set |
| Data set | Which reusable list backs an Autocomplete field | |
| File type | Limits an upload to images, PDFs, or both | |
| Required | The booking cannot be saved without an answer | Turn on for anything you intend to reconcile or report on later |
| Show in email | Puts the answer in booking confirmation emails | |
| Show in User Portal (Resource schedule) | Colleagues viewing that resource’s schedule can read the answer | Leave off for anything commercially sensitive |
| Show for service staff | The answer reaches the people fulfilling service requests | |
| Show for service manager | The answer reaches service managers |
Whatever these switches say, the answer always reaches the booking’s own detail, the approval screen, and the booking export — one column per field.
Field types
| Field type | Accepts |
|---|---|
| Text | One line of free text |
| Rich text | A formatted paragraph |
| Number | A number. Drops leading zeros and prefixes, so not for identifiers like PRJ-0042 |
| Phone number | A telephone number |
| Date | A calendar date |
| Time | A time of day |
| Date & time | Both together |
| Yes / No | A single switch |
| Select | One choice from the options set on the field |
| Multiple select | Several choices from those options |
| Autocomplete | One entry from a data set, searched as the person types |
| Upload file | One file, of the accepted types |
| Upload multiple file | Several files |
Data sets
A data set is a reusable list of options that Autocomplete fields read from. Define it once and every form can use it — which is what separates it from Select, whose options live on the one field that declares them.
Open Data set| Setting | What it does | When to change it |
|---|---|---|
| Name | Names the data set in the picker on a field | |
| Entries | The rows themselves | |
| Key | The code stored alongside the answer | Set it to whatever your other system reconciles on. Renaming the display text later then leaves past bookings intact |
| Display text | What the person booking reads | |
| Import from Excel | Loads the rows from a spreadsheet | For any real list — a chart of accounts is not worth typing |
| Export | Writes the rows back out | Take one before a bulk change, so a bad import can be undone |
Which form a booking uses
A booking can reach a form by three routes, and they are tried in a fixed order.
A booking purpose override wins outright; otherwise the selected resources decide; otherwise the default display form.
- A booking purpose carrying Override booking form wins outright. That form replaces everything else. Turn the override on and choose no form, and the booking gets no fields of your own at all — the resources’ forms do not step back in, and neither does the default display form.
- Otherwise the selected resources decide. Selecting several merges their forms rather than picking the strictest, so a booking spanning a room and a parking space asks everything either of them asks, each question once.
- Otherwise the default display form. This is what somebody sees before they have picked anything, which is why a form can change halfway through a booking: the moment a room is chosen, the room’s own form replaces it and a field already filled in can vanish.
A booking purpose, with Override booking form turned on.
What this does not control
- Who may book at all. Team spaces and resource policies decide that — see Booking rules reference. Nothing here changes who can reach a resource.
- Whether approval is needed. That is the resource policy, not the form.
- Whether a reviewer can read your fields. The resource policy carries its own switch for that.
- What a panel or signage shows as the booking’s title. A field can be promoted into the panel title, but that is set on the player configuration.
- Visitor forms. Visiting has its own form builder on its own screen, and the two never share fields or data sets.