Quick summary
Event registration forms have to do more than collect a name and an email address. In Orbance, answers in the logic step set tags. Those tags then control which fields, notices and tickets appear in the booking flow, with AND or OR rules.
- One logic, three levers: questions set tags, tags filter fields and messages, and the same tags show or hide pricing tiers.
- Ask only what you need: membership proof, overnight stay or a company invoice appear only after the matching answer.
- 15 extra field types plus standard fields, optionally per ticket or per person, in the same flow as the shop and the WordPress embed.
Related: Registration forms with tag logic · Attendee management for clubs · Event pricing tiers
Why a static registration form fails on complex events
A conference form that asks everyone the same questions creates two problems at once. Guests fill in fields that do not apply to them, and organizers still miss data where proof, contingents or add-ons sit. Members should see the member rate, guests the standard rate. Anyone who wants a hotel night needs an arrival date and the hotel ticket. Anyone who chooses “invoice to company” must give a company name and address. Anyone outside the audience should not be able to book at all.
Orbance models that in one form template. It is not a survey tool next to the shop. It is the first stretch of the booking flow: logic, session, tickets, data, review, checkout. Public booking runs in the ticket shop, including the WordPress embed.
How tag logic works
Tags are the control system. You create them on the form, for example member, guest, overnight or company. In the logic step, the booker answers questions with fixed options, typically yes/no or several alternatives. Each option can set one or more tags. An option can also end the booking, with a notice, for example when the event is open only to an eligible group.
What becomes visible next depends on the tags that are set:
- Follow-up questions and messages. Later questions or notices appear only when the tag condition matches.
- Standard fields and extra fields. Company, file upload or arrival date stay hidden until the matching tag is active. Hidden values are not kept.
- Tickets and pricing tiers. On the event you attach form tags to a tier under the booking-form dependency. With no tag condition, the tier stays visible (after session and sales window). With a condition, people only see tickets that match their answers.
AND means every selected tag must be set. OR means at least one is enough. The same rule applies to questions, messages, fields and pricing tiers.
One modelling detail matters: a pricing tier with no tags stays visible to everyone. If you want to hide the guest rate from members, the answer “No” should set a guest tag, and the guest ticket should require that tag. Otherwise members would see both rates.
What you can model with it
Member rate and guest ticket. Question: “Are you a member?” Yes sets member, No sets guest. The discounted ticket requires member, the standard price requires guest. Optionally, Yes is followed by a file upload for the membership card, visible only with the member tag.
Overnight stay as an add-on. Question: “Do you need a hotel night?” Yes sets overnight. Then the overnight ticket appears, plus a date field for arrival and a notice about check-in time. No hides the whole package.
A package only in combination (AND). A member overnight package requires member and overnight. Anyone with only one of the two does not see the package, but can still see the single tickets tied to one tag each.
A VIP notice for several roles (OR). A speaker dinner or sponsor lounge appears if speaker or sponsor is set. One field covers both groups, without duplicating the form.
End the booking on purpose. Question: “Is this course approved for your profession?” The No option ends the booking and shows a notice, instead of offering a ticket that would have to be cancelled later.
Company invoice. Question: “Should the invoice be issued to a company?” Yes sets company. Then the standard company and address fields become required, plus an optional extra email field that receives only the offer.
Ticket types such as attendance, overnight stay or add-on can also be combined through cart prerequisites. Tag logic decides which tiers appear at all. Quantity rules between ticket types (for example one dinner per attendee) run independently of that.
Standard fields for data capture
Contact data sits in the data-capture step, after ticket selection. Each standard field can be enabled on its own, marked required, and optionally bound to tags. You set placeholder and help text per field.
- First name and last name. Last name is required by the system.
- Email, with address confirmation in the shop.
- Company, typically bound to the company tag.
- Address as a composite field: street, postcode, city, region, country, with input suggestions.
- Phone.
Signed-in visitors see first name, last name, email and address prefilled. The booking is linked to the account. Booking without a login remains possible.
All extra field types
Extra fields sit next to the standard fields, globally on the booking or in per-ticket capture. Required state, help text, placeholder and tag visibility work the same way. Checkbox and switch need a description. Dropdown, radio and multiple choice need at least two options.
| Field type | Typical use |
|---|---|
| Text | Short free text, for example a membership number or table request |
| Text area | Longer notes, allergies, a motivation statement |
| An extra address. Optional: also send to this address, or for offers send only to this address (then required) | |
| Phone | An extra number besides the standard phone field |
| Number | Numeric values, for example number of accompanying children |
| URL | Website, portfolio, profile page |
| Date | Arrival, exam date, date of birth |
| Time | Arrival time, a preferred time slot |
| Dropdown | One option from a list, compact when there are many values |
| Single choice (radio) | One option, all choices visible, good for a few clear alternatives |
| Multiple choice | Several checkboxes, for example workshop interests or catering |
| Checkbox | A single confirmation with explanatory text |
| Switch / toggle | On/off, for example a newsletter or a public attendee list |
| Address | Another address, for example a different billing address |
| File | Proof as PDF, JPEG, PNG or WebP, 5 MB maximum |
File uploads fit a student ID, membership certificate or attendance requirement. Show them only when the matching tag is set, so guests who do not need to upload anything never see the step.
Data per booking or per ticket
Global data capture belongs to the whole booking: one contact, one billing address, company once. For workshops, room contingents or personalised badges you turn on per-ticket capture. Per ticket (or per person, when a pricing tier covers several people) you collect first name and last name plus extra fields from the same type catalogue, also with tag filters.
Example: three workshop tickets in one booking, each attendee with a name and an allergy note, while email and payment stay once on the booker.
Templates, one form per event, lock after sales
Form templates live at organisation or provider level. You assign exactly one template to an event, duplicate variants and archive unused forms. Questions, fields and messages sit in a fixed order. The ticket shop follows that timeline, on the direct shop link and in the WordPress plugin.
Once tickets have been sold through the form, the flow is locked. Name and description stay editable. The structure stays stable for existing bookings. Answers land in bookings and attendees, together with tickets, payment status and later check-in.
Booking on request and the waitlist use the same form flow. The waitlist itself is a short form per pricing tier (name, email, consents), independent of tag logic. Access codes and capacity sit on the pricing tier after tags have decided which tickets are visible.
FAQ: registration forms and tag logic
What are tags on a registration form?
Tags are invisible marks set by an answer. They control which later questions, fields, notices and pricing tiers the booker sees. With AND every selected tag must match, with OR at least one is enough.
Which field types does Orbance offer?
Standard fields are first name, last name, email, company, address and phone. On top of that there are 15 extra types: text, text area, email, phone, number, URL, date, time, dropdown, radio, multiple choice, checkbox, switch, address and file upload.
Can tags hide tickets as well?
Yes. On the event you attach pricing tiers to tags from the form. In the shop, only tiers whose tag condition is met appear, plus tiers with no tag condition. A member sees the member rate, a guest the standard price, without two forms.
Can I collect data per attendee instead of once per booking?
Yes. Per-ticket capture takes first and last name plus extra fields per ticket or per person. Contact and billing data stay once at booking level.
Can one form run on several events?
Yes. Templates belong to the organisation or a provider. Each event has exactly one active template. For variants you duplicate the form, instead of changing a live form after the first sale.
Conclusion
Complex registrations rarely fail because there are too few fields. They fail because every field always applies to everyone. Tag logic turns that around: answers set tags, tags filter fields, notices and tickets. You model member rates, overnight stays, proof, company invoices and eligibility rules in one template, with the full field catalogue and the same path in the ticket shop.
Forms with tag logic → · Start for free → · Attendee management for clubs →