A donor signs up for your spring lecture series. She wants the lecture, the reception afterward, and a seat at the members-only dinner. In your head that is one person with three choices. In Altru, an event registrant is usually tied to a single registration option for that event, so the second and third choices have nowhere obvious to go.
This article explains why that happens, the workarounds administrators actually use, and how to pick the one that won’t make your reporting a mess six months from now.
Why one registrant gets one option
Altru models event registration as a person attending an event at a particular price. The registration option is that price and label: “Member,” “Nonmember,” “Student,” “Table host,” and so on. It answers the question “what kind of attendee is this person, and what did they pay?” It is not designed as a shopping cart of add-ons attached to a single registrant.
That works fine for simple events. It breaks down when the options aren’t really attendee types but separate things someone can buy: a meal, a workshop session, a parking pass, a printed program. Those are products, and the registration option field was never meant to hold a list of products.
Before you build a workaround, confirm the limit in your own environment. Altru is updated over time, and how your events are set up matters. Try registering a test constituent for two options on the same event in a sandbox or on a test event you can delete afterward. If your version allows it cleanly, you may not need anything below. If you are unsure what you are seeing, Blackbaud support can confirm the current behavior.
Workaround 1: Build combination options
If the number of choices is small, create registration options that represent the combinations people actually buy:
- Lecture only
- Lecture + reception
- Lecture + reception + dinner
Good for: events with two or three add-ons and a handful of realistic combinations. Registrants still get exactly one option, and attendance and revenue stay on one event.
Watch out for: the math gets ugly fast. Three independent add-ons with member and nonmember pricing can mean a dozen or more options, and staff will pick the wrong one. Headcounts for the dinner also have to be added up across every option that includes it, which is easy to get wrong when the caterer wants a number by Thursday.
Workaround 2: Split the add-ons into their own events
Treat each component as its own event: the lecture, the reception, and the dinner are three events, and the same constituent registers for each one they want. Many organizations group these under a shared naming convention or event category so they’re easy to find together.
Good for: components with their own capacity, their own date or time, or their own guest list. You get a clean registrant count for each piece, which is exactly what the caterer or room setup crew needs.
Watch out for:
- Registering one person for three events takes longer at the desk or over the phone. Write down the order staff should follow.
- Reporting on “who bought the full package” means combining registrants across events. A constituent query that pulls registrations for all related events, grouped by constituent, handles this.
- If the add-ons are sold online, check how your registration web form handles multiple events before you commit. Test the full purchase as a guest would.
Workaround 3: Sell the add-on as an item, not a registration
Some add-ons aren’t really attendance at all. A parking pass, a book, or a boxed lunch can be sold as a separate item in a sales transaction instead of a registration. The registrant keeps one registration option, and the add-on is recorded as its own line of revenue.
Good for: physical goods or fees that don’t need a guest list.
Watch out for: the add-on won’t show up on the event’s registrant list, so whoever runs the event day needs a separate report. Make sure your finance team knows which GL accounts these items post to before the first sale.
Workaround 4: Record the extra choice on the registrant
When the second “option” has no price and is really a preference (meal choice, session track, T-shirt size), don’t make it a registration option at all. Capture it in a way you can query later, such as an attribute or a note your team uses consistently. Whether a given field is available on event registrants in your setup is worth checking in a test record first.
Good for: free selections where you only need a count or a list.
Watch out for: free-text notes are hard to report on. If you need counts, use a field with a fixed list of values.
How to choose
Ask three questions about each extra choice:
- Does it cost money? If not, record it as a preference (Workaround 4).
- Does it need its own headcount or capacity? If yes, make it its own event (Workaround 2).
- Is it a thing rather than an experience? If yes, sell it as an item (Workaround 3).
If none of those apply and you only have a few combinations, combination options (Workaround 1) are the simplest path.
Plenty of events end up mixing approaches: separate events for the lecture and dinner, an item for parking, a meal preference on the dinner registration. That’s fine. What matters is that you pick the setup before registration opens, document it in a short one-page guide for staff, and build the query you’ll use for headcounts at the same time. Changing the structure after people have registered means moving records by hand.
Quick answers
Can I just register the same person twice on one event with different options?
Sometimes it’s possible, but it usually creates a duplicate-looking registrant that inflates headcounts and confuses check-in. Test it in a sandbox before trying it on a live event.
Which approach keeps revenue reporting cleanest?
Separate events or separate items, because each piece of revenue lands on its own line. Combination options lump everything into one price, so you can’t easily see what the dinner alone brought in.
