Most booking events benefit from collecting a few extra fields at booking time — which teacher do you want to meet?, any dietary requirements?, who is attending?. PortalHQ handles this by linking each booking event to a custom form built in the Forms module.
How the link works
A booking event can point at one Event Booking Form. When a parent goes to book, they pick a session (if the event has sessions) and then fill in the form. Their responses are saved alongside the booking submission and appear in the staff submission list.
If you don’t link a form, parents just submit their booking with no extra information.
Building the form
Booking forms are built in the Forms module (Fobi). Important constraint: only forms with the type Event Booking Form show up in the booking event dropdown. Regular forms won’t appear.
To build one:
- Go to Forms → New form.
- Set the form type to Event Booking Form.
- Add the fields you need:
- Text fields for free-text questions (e.g. preferred teacher, comments).
- Single-choice or multi-choice for closed questions.
- Boolean for yes/no. - Save and publish.
Once the form is published, it’ll appear in the Booking event form dropdown on the booking event edit page.
Linking the form to the event
From the event edit page:
- Open the Booking event form dropdown.
- Pick your form.
- Save.
The form is now attached to the event.
What parents see
The form runs after the parent picks a session (if there are sessions). The standard flow is:
- Parent clicks the booking event from their dashboard.
- They pick a time slot.
- The custom form appears with the fields you defined.
- They fill it in and submit.
- The booking is created and they get a confirmation.
If there are no sessions, the form runs immediately after they click into the event.
Where the responses go
Form responses are attached to the submission. Open a submission from the event detail page and you’ll see the parent’s answers alongside the standard booking details.
The CSV export (see Viewing, managing and exporting submissions) includes the form responses as additional columns, so you can hand the file to whoever runs the event.
Editing the form after bookings exist
You can keep editing the form after parents have started booking, but be careful:
- Adding a field is safe — existing submissions just have no value for the new field.
- Removing or renaming a field breaks the link with existing submissions and you may lose the data.
- Changing field types is risky — values may not convert cleanly.
If you need a significant change, consider creating a new form and pointing the event at it. Old submissions keep their original form data.
Re-using forms across events
A single Event Booking Form can be re-used on as many booking events as you like. This is useful when you’re running the same kind of event repeatedly (e.g. PTI each term) — build the form once, attach it everywhere.
A note on form validation
Required fields in the form are enforced at submission time. Parents see a validation error and have to fill them in before the booking goes through.
If your event also has a slip prerequisite (see Setting eligibility and slip prerequisites), the slip is collected before the form runs.