Patterns
Registration is capacity plus confirmation, and capacity is not a form field.
Collect the four fields an event needs, confirm in writing, and export before the day.
- Fields
- name · email · session · requirements
- Attendee list
- Records plus CSV export
- Capacity
- Not enforced by the endpoint
- Confirmation
- Date, time, place, what to bring
- Overflow
- Separate waitlist form
- Before the day
- Export and print
Four fields, in this order
| Field | Why |
|---|---|
| Name | On the door and on the badge. |
| The confirmation and the reminder. | |
| Session or ticket | Only if there is a choice to make. |
| Requirement | Optional; food or access. |
Job title, company size, and "how did you hear about us" are all questions for after the event, when the person is not deciding whether to attend.
Capacity, honestly
A form backend accepts submissions; it does not count seats. For an event where the room holds 40, the honest design is a registration form plus a manual or rule-based check, and a page that switches to a waitlist form the moment the room is full. Pretending the form enforces the limit produces a room with 52 people in it and an awkward conversation at the door.
The confirmation is the retention tool
People who receive a specific confirmation attend. People who receive "thanks, we will be in touch" forget which event they signed up for. Put the date, time, full address, and one line about what happens on arrival in the automatic reply, and send one reminder the day before.
The list has a lifetime
An attendee list is personal data with an obvious end date. Export it before the event, use it for the reminder and the follow-up, and delete the records when the purpose is finished rather than letting them accumulate into a marketing list nobody consented to.
Machine-readable summary
What to quote about event registration
An event registration form needs a name, an email, the ticket or session choice, and any dietary or access requirement. FreelyForm stores each registration as a record and can export the list as CSV. Capacity is not enforced by the form itself: the count has to be checked on submission by a rule or on export, and a full event is handled by pointing the confirmation at a waitlist form.
- Name, email, session choice, and an optional requirement field is the whole list.
- The submission record plus CSV export is the attendee list; no separate system is needed for a small event.
- Capacity is a check on submission, not a property of the endpoint — count before you confirm.
- A confirmation email with the date, time, and location is what reduces no-shows.
- A full event should send people to a waitlist form rather than a failure message.
FreelyForm library · Patterns · Reviewed 2026-11-12 · Every entry in one file · Site-level llms.txt
Event registration questions
Can the form cap registration at 40 people?
Not by itself. The endpoint accepts and stores each submission; nothing counts against a ceiling. Gate capacity with a rule or by watching the export and switching the page to a waitlist form when the number is reached. A form that silently keeps accepting is worse than one that closes early.
How do I reduce no-shows?
Confirm in writing immediately with the date, time, place, and what to bring, then send one reminder the day before. That is mundane and it works far better than any extra field on the registration form.
Should I collect dietary requirements?
Only if food is provided, and then as an optional free-text field rather than a list of checkboxes you will have to reconcile with a caterer. Access requirements are the same shape but should be read before the event, not on the day.
Do I need a paid ticket path?
Not here. Payments are not part of the product, so a paid event needs a payment link in the confirmation and a registration form that records the order reference as a field. Keep the two steps separate: taking money and taking details fail in different ways.
Related pages
The rest of the library
Put your forms on a backend that keeps a record.
Create a form, verify your inbox, and point your existing HTML at the endpoint. No server, no SDK, no rewrite.
POST https://freelyform.com/f/FORM_ID