Registering several people (Pro)

One person signing up for four is the ordinary shape of a workshop, a dinner or a coach trip. Without somewhere to put it, that arrives as four separate registrations you have to recognise as one booking afterwards — or, far more often, as one registration with "+3" typed into a notes field, which nothing counts and nobody charges for.

Switch this on and the form asks how many people are coming, then asks for each of the others by name.

Turning it on

On the form's Settings tab, under Group bookings:

1. Let one booking cover several people. The switch.
2. Most people per booking. Two to ten.
3. The question asking how many. Your own wording, or "How many people are you registering?"
4. Ask about each of the others — their name, their email address, both, or neither.
5. Count the maximum in people, not bookings.
6. Charge the price once per person.

The questions it writes

Switching it on adds ordinary questions to the form:

group_size	A number question, required, bounded by the maximum you set.
attendee_2_name, attendee_3_name, …	One per extra person, for whichever details you ticked.

Counting starts at two on purpose: the person filling the form in is the first person, and the form is already asking for their details further up.

They are real questions in the form's own question list, so they behave like every other one — reword them, rename the field so a webhook receives the key it expects, drag them where you want them. All of that survives the next save. What the panel keeps owning is the label's default, the question type and the number bounds.

Lower the maximum and the rows it drops are removed. Switch the feature off and all of them go.

What the person filling it in sees

The rows appear as the number goes up: put 3 and you get person 2 and person 3, and no others. This is enforced on the server as well as in the browser — a row for somebody who is not coming is not stored even if a browser posts it, and a required row for a person who is not coming never blocks a submission.

Counting people, not bookings

With Count the maximum in people on, a form with Maximum registrations of 30 is full at 30 people, however many bookings they arrived in. A party of four takes four places.

The total is worked out from the bookings themselves each time it is needed, so it is right after a response is deleted, and right on a form that had this switched on after it had already collected some. A booking that carries no count — one from before the feature, or one where the question was later removed — counts as one person.

Turn it off and the maximum counts bookings again, which is what it did before.

Charging per person

With Charge the price once per person on and Payments set up, a booking for four is charged four times the rate. It multiplies whatever the form would otherwise have charged, so it works with multiple event prices too — four people at the student rate is four student rates.

Turn it off to charge once per booking, whatever its size.

With the waiting list

They work together, and one thing is worth knowing: the waiting list counts registrations that hold a place, and this counts people. On a form using both, a party of four that arrives when two places are left goes on the waiting list as one booking — a booking is admitted or not as a whole, because half a party is not something anybody wants to be offered.

In the export and the webhook

group_size and each person's row are ordinary questions, so they are already columns in the Excel and CSV exports, entries in the responses summary and keys in the webhook payload.

The payload also carries the number on its own, so a receiving system does not have to know which question holds it:

{
  "group_size": 4
}

If the license lapses

The questions stay on the form and keep collecting answers — they are ordinary questions, and nothing removes them. What stops is the counting and the charging: the maximum goes back to counting bookings, and a booking is charged once. It all resumes when the license does.