A gala needs meal choices and table assignments. A members’ preview night needs to know who is bringing a plus-one. A lecture series just needs a name and an email. Altru handles all three as special events, and the registration screen staff see looks largely the same each time. That’s where the frustration starts.
The short version: Altru gives you real control over what you sell and track for an event, but very little control over the layout of the registration screen itself. Once you know which parts move and which don’t, you can usually get the information you need without fighting the screen.
What you can’t really change
The registration screen staff use to add registrants is part of the core application. As far as we know, Altru doesn’t let administrators rearrange its fields, hide sections they never use, rename labels, or add new free-form questions directly to that screen. If you have seen this done somewhere, it was likely done through configuration elsewhere (registration options, attributes) rather than by editing the screen itself.
If layout changes are a must for your organization, confirm the current limits with Blackbaud support before you plan around them. Product behavior changes over time, and support can tell you whether anything is available for your version. Just don’t expect a drag-and-drop form editor.
What you can shape
Registration options
Each special event has its own set of registration options, which are the prices and packages someone can register under. This is your most flexible tool. Naming matters more than people think: “Gala: Individual, Vegetarian” and “Gala: Individual, Beef” are clumsy, but they put meal choice right where staff can’t miss it and make it reportable. For small events with one or two choices, this is often the simplest answer.
Keep the option list short. Staff choose from it at registration time, and a list of twenty near-identical options slows everyone down and invites mistakes.
Guests and registrant details
Altru tracks registrants and their guests against the event. If you need to know who a guest is (not just that “one guest” is coming), get in the habit of adding the guest as a named registrant tied to the host. That takes more time at entry, but it’s the difference between a usable name-badge list and a pile of “Guest of Smith” entries.
Attributes for extra questions
For information that doesn’t fit a registration option, such as accessibility needs, dietary restrictions, or “how did you hear about us,” constituent attributes are the usual workaround. Set up an attribute category for the data point and have staff record it on the constituent record right after registering them.
Two caveats. First, attributes live on the constituent, not on the event registration, so a dietary restriction recorded for this gala will still be there next year. That can be useful or misleading depending on the data. Second, it adds a step outside the registration screen, so it only works if the step is written down and trained. Test how attributes behave for your setup in a sandbox before you roll it out.
Event-level details
Use the event’s own description, location, and related fields consistently so that queries and lists pull clean data. Inconsistent event naming is one of the most common reasons registration reports end up being cleaned up by hand in a spreadsheet.
A workable setup for most events
- List the questions you truly need answered. Be strict. Every extra question is another step for staff and another field that ends up half-filled.
- Sort each one. If it changes the price or package, make it a registration option. If it describes the person, make it an attribute. If it’s only needed on the night (table number, seating notes), consider keeping it on the event registrant list or a separate working document instead of the constituent record.
- Write a one-page entry guide per event type. Name the exact registration options and attributes to use. Seasonal and volunteer staff will follow a printed sheet far more reliably than a verbal briefing.
- Build the query before the event opens. Create a query that returns registrants, their registration option, guests, and the attributes you rely on. Run it after the first few registrations come in. If something is missing, you’ll find out with three registrants instead of three hundred.
- Review after the event. Note which fields staff skipped or misused, and adjust the guide for next time.
When the screen isn’t the real problem
Sometimes the push to customize the registration screen is really a sign that the event belongs somewhere else. A recurring timed program, like a weekly tour or a daily workshop, may fit better in Altru’s program and ticketing tools than as a special event. And for events where guests register themselves online, the questions you ask happen on the web side, not on the staff screen. In that case it’s worth looking at what your online registration form collects and how those answers land in Altru, rather than at the desk screen.
It’s also fine to decide a separate sign-up form is the right call for a one-off event with lots of custom questions. Just plan how and when the answers get back into Altru, and who is responsible for it, so the constituent records don’t drift.
Quick answers
Can I add a custom question to the special event registration screen?
Not directly, as far as we know. Use registration options for anything tied to price or package, and constituent attributes for everything else. Check with Blackbaud support if you need a definitive answer for your version.
Where should meal choices go?
For one or two choices, registration options are the simplest and easiest to report on. For more complex menus or allergy details, use an attribute and a clear entry guide.
How do I make sure staff enter everything?
A short written guide per event, plus a registrant query you check early and often. Nothing in the screen will force the extra steps, so the process has to.
