A registration form has two jobs that pull against each other. It has to be short enough that people finish it, and complete enough that your team can run the event. Conditional logic is how you do both: every question stays hidden until an earlier answer makes it relevant.

Below are six patterns we see again and again across conferences, workshops, community nights and members' events. Each one lists the fields, the rule, and the mistake to avoid. They all work in the Geiger Events registration form builder, and the more advanced variants work in Geiger Forms.

A quick note on how rules work

A conditional rule has three parts: the field it watches, an operator, and a value. "Show Which workshop? when Pass type equals Workshop." In Geiger Events each field can carry one show when rule based on another field's value. In Geiger Forms a field can carry several conditions using Equals, Does not equal, Contains or Is empty, and the field shows when any of them match.

The one rule that matters everywhere: a required question only counts as required while it is visible. Both products skip validation on hidden fields, so you can mark a follow-up as required without trapping people who never see it.

1. The workshop or track picker

Use it for: conferences with breakout sessions, training days, workshops and classes.

• Pass type — choice: Main stage only, Main stage + workshop.
• Which workshop? — choice, required, shown when Pass type equals "Main stage + workshop".

The mistake to avoid: using the form to cap workshop sizes. A form rule cannot count seats. If each workshop has its own capacity, make each one a ticket type or a slot with its own limit, and keep the form for the information you need about the person. See per-ticket questions for how the two combine.

2. The dietary follow-up

Use it for: anything with catering.

• Any dietary requirements? — choice: No, Vegetarian, Vegan, Halal, Kosher, Allergy, Other.
• Tell us about the allergy — long text, required, shown when the answer equals "Allergy".
• Please describe — short text, shown when the answer equals "Other".

The mistake to avoid: a single free-text "dietary requirements" box. You get "none", "N/A", "no", "-" and "nope", all of which your caterer has to read. A choice with a targeted follow-up gives you countable data. Geiger Events also rolls these answers up into a single dietary and accessibility report for the venue.

3. The professional details block

Use it for: B2B events, trade shows and anything with printed badges.

• Attending as — choice: Individual, On behalf of a company, Exhibitor.
• Company and Job title — shown when the answer is not "Individual" (in Geiger Forms, a Does not equal condition).
• Stand number — shown when the answer equals "Exhibitor".

Why it pays off: company and job title are exactly what badge printing and lead retrieval need. Collect them once, at registration, and they flow through instead of being retyped at the badge desk.

4. The plus-one

Use it for: parties, dinners, community events.

• Bringing a guest? — yes/no.
• Guest name — required, shown when the answer is Yes.

The mistake to avoid: treating the guest as a comment on the registrant. If the guest takes a seat, they should count against capacity and appear on the check-in list. Geiger Events has plus-ones and group registration built into registration itself — named guests are stored as a roster on the registration and counted in the party size — so use that rather than a free-text question.

5. The accessibility follow-up

Use it for: every in-person event.

• Do you have any access requirements? — yes/no, optional.
• How can we help? — long text, shown when Yes.

Why it is conditional: most people answer No, and a large empty text box invites people to write "no" in it. The follow-up only appears for the people who need it, and their answer lands on their attendee record so the door team can see it in the check-in app.

6. The application-then-approval flow

Use it for: invite-only dinners, vetted professional events, member organisations, speaker or scholarship applications.

• Why do you want to attend? — long text, required.
• Are you a current member? — yes/no.
• Membership number — shown when Yes.

Turn on an approval gate so each registration arrives as Pending, and approve or decline from the registrations inbox. If the application needs scoring or file uploads (a CV, a portfolio, a proof of eligibility), build it in Geiger Forms with calculated scoring fields, and invite accepted applicants to register in Events. For talks specifically, the call for papers flow is purpose-built.

Three rules of thumb

1. One question per decision. If a question only exists to decide which other questions to show, make it a choice, not free text. Rules cannot reliably match "yes", "Yes!" and "yeah".
2. Watch one field, not a chain of five. Deep chains of dependent questions are hard to test and harder to change later. If you need more than two levels, you probably need separate ticket types.
3. Test every branch. Fill the form once per path before publishing. It takes minutes, and it is much cheaper than emailing 300 people for the answer you forgot to ask.

If you are still choosing a tool, our buyer's checklist for registration software with conditional forms covers what to test in a trial. Otherwise, open Geiger Events, create a registration form, and try the first pattern — it takes about two minutes.