Event registration form fields, by event type

The complaints after an event are almost never about the form. They are about the badge that reads Katherine when everyone has called her Kate for thirty years, the vegan meal nobody ordered, and the person who arrived to find the breakout room up a flight of stairs. All three were settled weeks earlier, on the registration form, by a field somebody decided not to include.

Build the form from the day back

Write down what has to be produced before the doors open. Badges. A catering order with numbers by meal type. A room split. A check-in list. A joining email. An emergency contact sheet if anyone is going to run, climb or swim.

Each of those outputs names its inputs, and those inputs are your fields. Anything left over is a field you are collecting out of habit. Job title is a good test: if it appears on the badge or in the delegate list, keep it. If it is going to sit in a spreadsheet column nobody opens, it is costing you completions for nothing.

Run backwards like this and most registration forms shrink. The six event registration forms published in the example set here range from 8 fields to 21, with a median of 13:

Form	Fields	Format
Webinar registration	8	Conversational
Open day registration	10	Conversational
Conference registration	11	Classic
Workshop registration	15	Classic
Sports tournament registration	20	Classic
Fun run registration	21	Classic

The pattern in that spread is not event size. It is liability and logistics. The webinar needs an email address and a reason to attend. The fun run needs a date of birth, an age bracket, an emergency contact and a waiver, because somebody might get hurt.

Ticketing fields

Name, email and ticket type are the irreducible three. Add quantity where a person books for several people, and add the invoice details where the buyer is an organisation rather than a person: trading name, purchase order number, and the address the invoice goes to. The gala booking example on this site carries all of those because a table of ten is bought by a finance team, not by a guest.

One thing to be clear about: the form builder does not take payment. There is no card field among the 41 component types and no basket. A registration form captures the order and the money is settled elsewhere, by invoice or by sending people to a payment page from the thank-you screen with the redirect add-on.

There is also no registration cap. Nothing counts submissions against a limit, so a form does not close itself when you are full. Access control offers four modes, public, secret key, login required and domain restricted, and switching mode or unpublishing is how you stop taking entries.

Logistics fields: dietary, accessibility, session choice, t-shirt size

Dietary requirements belong on a form only where you are ordering food in advance. Ask it as free text rather than a tick list. Every tick list is missing somebody’s combination, and the builder’s Other option is a dead property: it is declared in the field types and read by no renderer, so ticking Other gives the respondent nowhere to type. If you want a list, follow it with a short text field of your own.

Accessibility requirements should be on every registration form, including the ones with no catering. The W3C’s guidance on accessible presentations is direct about this: ask speakers and participants about their accessibility requirements, for example by including a question on conference registration forms, and invite participants to include specific requests. Leave it as an open question, and say who reads it. A closed list of three options tells somebody with a fourth need that you were not really asking.

Session or date choice earns its place when the answer changes a room allocation, a catering split or a start wave. Radio and checkbox options can be laid out in one, two or three columns, which makes a long list of breakout sessions scannable. A dropdown cannot do that, so use radio buttons once the list is worth reading side by side.

T-shirt size goes on the form if, and only if, there is a shirt.

Communication fields: badge name, company, consent to photos

If you print badges, ask what to print. A separate short text next to the legal name, labelled as the name for the badge, costs one field and removes the single most common day-one complaint. The conference example published here uses one name field, which is the usual choice and exactly the design that produces the misspelt badge.

Organisation and job title are for the badge and the delegate list, so they are optional almost everywhere and required only at events where the room is the point, like a gala or a trade night.

Photo and video consent deserves its own question rather than a clause inside the terms tick. Under the Australian Privacy Principles, APP 3 applies a “reasonably necessary” test to what you collect, and where consent is the basis for handling information the regulator’s guidance requires it to be voluntary, informed, current and specific, given by somebody with capacity to understand it. The same guidance is explicit that consent cannot be inferred simply from having given notice. Naming the jurisdiction matters here, and none of this is legal advice: check your own rules before you publish.

Field matrix by event type

The table below marks each of twelve fields required, optional or skip across five event types. A few of the cells are worth explaining.

Emergency contact is required for the fun run and skipped everywhere else, because it is the only one of the five where somebody is under physical load. Dietary requirements are required at the gala because a seated dinner has to be ordered by meal type, and skipped at the workshop because there is no catering to change. Organisation is required at the gala because the invoice and the guest list both need it. And terms acceptance is skipped at the open day, because nothing is being bought and nobody is signing anything.

Paging a long registration into steps

A classic form can be laid out three ways: flow, single column, or paginated. Paging is the right answer at around twenty fields, or where the sections are genuinely separate jobs, such as a team entry that asks for the manager’s details first and the squad list second. Below that, a single page beats steps, because the respondent can see the whole ask and decide once. The guide linked at the foot of this post covers the mechanics.

One trap worth knowing before you build a long form: on a published classic form, the field description is only rendered for file upload and photo. Every other field drops it. So an explanation that a respondent must read, like what you will do with a medical note, has to go in a paragraph block above the field, or into the label itself.

The example, annotated

The conference registration example is 11 fields in three sections: who is coming, your ticket, access and catering. Only four are required, and they are the four the event cannot run without: attendee name, email, ticket type and the terms tick.

Dietary and accessibility requirements are both open text and both optional, sitting together at the end under a heading that says what they are for. Organisation, job title and mobile number are optional, which is the correct call for a conference where the badge only needs a name. Compare it against the fun run registration form, which is twice the size for an event that is half the length, and the extra fields are all waiver, medical and emergency contact.

If you want the field count itself down rather than reorganised, the sibling post on improving form completion rate publishes what the whole 55-form example set looks like by field count, and ranks the levers by how much they move. And if your registration really is long enough to need steps, the multi-step form builder page shows what paging looks like once it is built.