A general admission buyer shouldn’t have to answer anything beyond name and email. A chaperone ticket for a school group might need the school name and grade level. A sensory-friendly morning slot might need a field for accommodation notes. A behind-the-scenes tour might need a liability acknowledgment and a shoe-size question. Put all of that on one online form and every buyer wades through questions that don’t apply to them, and the answers you do get are harder to trust.
So the real question is: can an Altru web form show different registration questions depending on which ticket someone picks? And if not, what’s the cleanest way to get the right information from the right buyers?
Start by confirming what your Altru setup actually does
Altru lets you collect extra information during online sales, and events with registrations have their own options for gathering details about each registrant. What’s less clear-cut is whether a single web form can show or hide questions based on the price type or ticket a buyer selects. Behavior can differ between event registration forms and general ticketing forms, and Blackbaud updates the product over time.
Rather than relying on anyone’s memory (including ours), confirm it directly:
- Build a test in a sandbox or on an unpublished form. Set up two price types, add your questions, and see whether you can tie a question to one price type only.
- Check out as a buyer. Pick each ticket type in turn and note exactly which questions appear.
- Look at where answers land. Find the responses on the constituent or registrant record and confirm you can pull them into a query.
- Ask Blackbaud support if the test is inconclusive. Describe the specific scenario (“question X only for price type Y”) so you get a direct yes or no.
If conditional questions work the way you need, you’re done. If they don’t, the options below are what experienced admins usually fall back on.
Workarounds, from simplest to most involved
1. Split the offering into separate events or programs
If a ticket type needs meaningfully different information, it may really be a different offering. A school group visit, a sensory-friendly session, and a members-only preview can each be their own event or program with their own registration setup and their own web form. Each form asks only what that audience needs.
Trade-off: more items to build and maintain, and reporting across them takes a bit more query work. Capacity also has to be managed per offering, which matters if they share the same physical space or time slot.
2. Use one form, but write questions that work for everyone
Sometimes the cheapest fix is wording. “Does anyone in your party need an accommodation? (optional)” works for every buyer. Keep required fields to what every ticket type truly needs, mark the rest optional, and label them clearly (“School groups only: school name”).
Trade-off: you’ll get blanks and some answers from people who didn’t need to respond. Plan to clean those up in your query rather than expecting perfect data.
3. Collect the extra details after purchase
For information you don’t need at the moment of sale, such as a tour participant’s shoe size or a field trip’s arrival time, send a follow-up to buyers of that specific ticket type. Pull a query of transactions by price type, then send a short form or a request to reply with the details. Record the answers as attributes or notes on the constituent or registrant record so they’re easy to find later.
Trade-off: not everyone responds. Build in a reminder and a fallback (asking at check-in) for the stragglers.
4. Gather it at the door
For small groups or one-off programs, asking at arrival can be perfectly fine. It works poorly for anything you need to know in advance, like staffing an accommodation or ordering supplies.
Decide where the answers will live before you build anything
The question form is only half the job. Whichever route you take, decide up front:
- Record level. Does the answer belong to the buyer, to each registrant, or to the transaction? A school name belongs to the group; a dietary note belongs to a person.
- Field type. Use attributes with fixed choices where possible. Free-text answers are hard to report on.
- Who uses it. If the education team needs a list of grade levels the week before a visit, build that query now and test it with dummy orders.
- Retention. Accommodation and health-related details deserve care. Collect only what you’ll act on, and decide who can see it.
A quick way to choose
- Questions differ a lot and the audiences are distinct: separate events or programs.
- Questions differ slightly: one form with optional, clearly labeled fields.
- Details aren’t needed at checkout: post-purchase follow-up.
- Small, informal program: ask at check-in.
Another option for the online checkout
Some organizations decide the Altru web form itself is the constraint and replace the buyer-facing page while keeping Altru underneath. Social Good’s Checkouts is a branded, mobile-friendly checkout for tickets, memberships, and donations that writes data back to Altru. If ticket-specific questions are a deciding factor for you, ask us to walk through your exact scenario before assuming any tool handles it the way you need.
Quick answers
Can I make a question required for one ticket type and optional for another?
Test it in your own Altru setup first. If it isn’t supported, separate forms or a post-purchase follow-up are the reliable alternatives.
Where should I store registration answers so I can report on them?
On the record level the answer describes (buyer, registrant, or transaction), ideally as attributes with fixed choices, so a query can pull them cleanly.
