Almost every event platform advertises "custom registration forms". In practice that phrase covers a very wide range: at one end, a fixed list of extra text boxes bolted onto checkout; at the other, a real form engine where questions appear and disappear based on earlier answers, differ per ticket type, and write their answers somewhere your team can actually use.

If your events are simple — one ticket, one question about dietary needs — the difference barely matters. The moment you run a conference with workshop tracks, a members' event with approval, or a paid event where each attendee in a group needs their own details, it matters a lot. This checklist is what we look for, and what we built Geiger Events and Geiger Forms around.

1. Can a question depend on another answer?

This is what "conditional forms" should mean: a question is shown only when an earlier answer makes it relevant. Pick "Workshop day" and you are asked which workshop; pick "Standard" and you are not. Answer "Yes" to accessibility requirements and a follow-up text box appears.

Things to check:

• Which operators exist. "Equals" is the minimum. You will quickly want "does not equal", "contains" (for multi-select or free text) and "is empty".
• Whether hidden questions are still required. A required question that is hidden must not block submission. This sounds obvious; plenty of tools get it wrong and attendees get stuck on an error for a field they cannot see.
• Whether hidden answers are discarded. If someone picks a workshop, changes their mind, and switches to a standard pass, the old workshop answer should not end up in your export.

In Geiger Events, each registration-form field can carry a show when rule — show this field when another field equals a value. Geiger Forms goes further with Equals, Does not equal, Contains and Is empty conditions, and it skips required-field validation for anything the respondent cannot see. We walk through concrete patterns in six conditional registration form examples.

2. Can questions change per ticket type?

Event-level questions are asked of everyone. Real events need more than that: VIPs get asked their T-shirt size, exhibitors get asked for a stand number, students get asked for their institution. If the only option is one shared form, you end up with a long form full of "skip if not applicable" instructions — the exact problem conditional logic was meant to solve.

Look for per-ticket questions that are additive (they appear on top of the event's shared questions) and, for group purchases, asked once per attendee rather than once per order. Otherwise a buyer purchasing five seats gives you one name and four blanks. We cover this in depth in collecting attendee data before payment.

3. Are answers collected before payment?

If the form runs after checkout, some attendees will pay and never finish it. Your badge list then has holes you will be chasing by email the week before the event. Questions should be collected before the handoff to the payment provider — for free and paid tickets alike — and stored so they survive the round trip to checkout.

4. Does registration handle capacity, waitlists and approvals?

The form is only half of registration. The other half is deciding who gets in:

• Capacity limits that stop sign-ups when the room is full.
• A waitlist with auto-promotion, so a cancellation is filled without you watching the list.
• Approval gates for invite-only or vetted events, with approve/decline and a clear "pending" state for applicants.
• Plus-ones and group registration, with every guest counted against capacity individually.
• Registration windows — open and close dates — and member-only access.

All of these live in the Geiger Events registration and RSVP flow. If you are evaluating tools, test the waitlist specifically: register past capacity, cancel one confirmed attendee, and see whether the next person is promoted without a manual step.

5. Where do the answers go?

A dietary answer that sits in a CSV export is a dietary answer that nobody reads until the caterer calls. Check whether answers attach to the attendee record, whether there is an aggregated view (for example, a single dietary and accessibility report for the venue), and whether they flow into the rest of the tooling:

• Your attendee CRM, so the person's answers are visible next to their history.
• Badge printing, so a job title or company collected at registration ends up on the badge.
• The check-in app, so staff at the door can see flags like accessibility needs.
• Email and SMS, so you can message only the people who picked a given workshop.
• Webhooks and the API, if another system needs the data.

6. Does the form look like your event?

Registration usually sits on the event page, so it should inherit the page's design. A form hosted on someone else's domain, styled with someone else's brand, costs you conversions. Check for a proper event page builder and custom domains and branding, and make sure the confirmation page after submission is editable — it is where you tell people what happens next.

7. Do you need an event platform, a form builder, or both?

This is the question most checklists skip. There are two legitimate shapes of "registration software":

• An event platform with a form built in. Best when registration is tied to tickets, capacity, check-in and badges. That is Geiger Events.
• A general form builder. Best for applications, sign-ups and intake that are not really events — a course application, a volunteer roster, a grant submission — or when you need calculated fields, scoring or file uploads. That is Geiger Forms.

Because both are part of the same suite, you do not have to pick one forever. A common pattern is an application in Forms (with scoring and file uploads) followed by registration in Events for the people you accept.

A quick test script

Whatever tool you are evaluating, build this form in a trial account. It takes about fifteen minutes and exposes most weaknesses:

1. A required "Ticket type" choice: Standard, Workshop, Exhibitor.
2. A required "Which workshop?" choice shown only for Workshop.
3. A required "Company" field shown only for Exhibitor.
4. An optional "Accessibility needs?" yes/no, with a follow-up text box shown only for Yes.
5. Register as Standard and confirm you are not blocked by the hidden required fields.
6. Buy three Workshop seats and confirm each attendee gets their own workshop question.
7. Set capacity to two and check the third registration lands on the waitlist.

If a tool passes all seven, it will handle most real events. If you want to try it on ours, Geiger Events comes with a 15-day free trial, and the workshop and class registration and conference guides show the same flows in context.