Custom Checkout Fields

Each question is stored as its own row against the event and saved the moment you add it, so there is no separate save step to forget. Two things govern whether buyers actually see them: the question rows themselves, and an attendee-questions switch on the event — turn the switch off and the questions stay defined but are not asked. Answers are written against the order's registrant record rather than the order id, and that is the link the attendee report and the exports follow when rebuilding who answered what.

A checkbox question renders as a single agree control and records the value yes when it is ticked. Marking it required has real teeth: checkout will not advance to payment while the box is empty, and the error names the specific question rather than showing a generic warning. On the storage side, checkbox and select answers are written into a selected-options array while free-text answers go into a separate detail field, which is why both come back as plain readable text in the attendee report.

The scope you choose changes what shows up later in reports, not just what's asked at checkout. A per_order answer appears once against the whole purchase, so it's the right choice for anything true of the buyer rather than of each guest. An each_attendee answer appears once per ticket, which is what makes it possible to see, say, five different dietary answers inside a single five-ticket order instead of one answer standing in for everyone.

The type you pick isn't just cosmetic — it decides what BrightStar will accept. An email field rejects something that isn't a valid address before checkout can continue, and a phone field expects a country code alongside the number. A select field is the only type where you define the possible options yourself, which is what makes it suited to closed choices like a meal preference rather than open-ended ones.

There is a mechanical reason the cost compounds for repeat buyers. BrightStar remembers a buyer's own contact details between checkouts — name, email, phone, address — but deliberately never stores their answers to event-specific questions, since those belong to one event rather than to the person. So every required question is retyped in full on every purchase, including by the people who buy from you most often. Anything that could reasonably be asked by email after the sale usually does not need to sit in the checkout path.

In the export the join runs on the registrant record attached to each order, each question becomes its own column, and checkbox and select answers are flattened into a comma-separated string so the file stays one row per order. BrightStar stores the same answers in two places — a dedicated answers table and a snapshot on the order itself — because different checkout paths and different reports read from different sources. Running a report is read-only either way; nothing about generating one alters what an attendee submitted.

Questions are saved as their own records attached to the event rather than as part of the event description, which is what allows them to be added, edited or removed after publishing without rebuilding anything. They are written to your event when you publish and then served to the buyer as part of checkout, so a question you add later starts appearing to buyers without any further action from you.

The options list is only stored for dropdown questions, which is worth knowing if you build a question as a dropdown, add options, then switch it to short text — the options are not carried across, since a free-text field has no use for them. Choosing the type well is the single biggest factor in how usable the answers are afterward: anything you intend to count should be a dropdown.

The judgement call is what genuinely warrants it. Required is right for anything affecting safety or logistics — an emergency contact, a serious allergy, a waiver acknowledgement — because you would otherwise be chasing it by email. It is wrong for anything merely interesting, since every required field is another point where a buyer can abandon a purchase. A reasonable test: if you would not personally email someone to get the answer, do not require it.

That per-attendee linkage is what makes the answers operationally useful: a dietary note is only worth having if you know whose plate it belongs to, and an emergency contact is only worth collecting if it is attached to a name on your door list. Because the answers ride along with the attendee export, the practical workflow is to pull the export before the event and hand the relevant columns to whoever needs them — the caterer, the front desk, the facilitator.

The consequence to plan for is that people who bought before you added the question have no answer on file for it, so your export will show gaps for those attendees rather than being retroactively filled in. If the question matters for everyone, the usual approach is to add it for new buyers and email the earlier cohort separately, rather than assuming the export is complete.

The practical mitigation is to keep the required set small and to prefer dropdowns and checkboxes over free text, since choosing from a list is far faster than typing. Helper text also earns its place here — a one-line explanation of why you are asking for an emergency contact converts a suspicious-looking field into an obviously reasonable one, and buyers abandon far less often when the reason is visible.