Here’s the short version: in many Altru setups, whether a program collects registrant details is decided when the program is built, and there’s no simple switch to flip it back and forth once tickets are on sale. If you need a program to require registration in some seasons and not in others, you’ll usually manage that with how you structure programs, not with a single toggle.
Below is what preregistration actually changes, why turning it off and on mid-stream is awkward, and the setups that admins use to get the same result.
What preregistration changes in a program
A program without registration sells tickets: a quantity, a price type, an event time. A program with registration also ties each ticket to a person, a name, and often extra details like age, allergies, or emergency contact. That’s what you want for camps, classes, sleepovers, and workshops, where staff need a roster.
The trouble is that the same program can serve both purposes over a year. A behind-the-scenes tour might need names during a capacity-limited pilot, then go back to simple ticketing once it’s routine. A family program might require registration only when it’s a drop-off format. Staff reasonably expect to switch the requirement on the program and move on.
Why it’s hard to switch once sales exist
When registration is part of the program, Altru stores registrant records against each sale. Turning that off after sales exist would leave some orders with registrants and some without, and it raises questions about rosters, reports, and refunds. That’s the likely reason the setting tends to be fixed, or at least restricted, once a program is in use.
Altru’s behavior here has shifted across releases, and it can also depend on whether events already have sales. Before you plan around any of the options below, confirm in your own environment: open the program in edit mode and see which registration options are still editable, try the change on a test copy, or ask Blackbaud support how your version handles it. Don’t test on a live program with real orders.
Workarounds that hold up
1. Keep two versions of the program
The most reliable approach is two programs with clear names, for example “Night Tour” and “Night Tour (Registration).” Each has its own events. When the requirement changes, you stop scheduling events on one and start scheduling them on the other. Reports stay clean because each program is consistent internally.
The cost is a little reporting work: if leadership wants totals for “Night Tour” across the year, build a query or report that combines both programs. Set that up once and save it.
2. Copy the program when the season changes
If your Altru version lets you copy a program, you can duplicate it with the registration setting changed and retire the old one when its last event is done. This keeps history in the original and gives you a clean start. Check what the copy carries over (prices, sales methods, capacity) before you schedule anything on it.
3. Control where each version can be sold
Sometimes the real need is “require names online, but not at the desk,” or the reverse. Look at which sales methods (daily sales, advance sales, online, group sales) each program is available through. Making the registration version available only where you need names, and the plain version everywhere else, can get you most of what a toggle would.
4. Collect details outside the program
If you only need a name or a single answer occasionally, some teams keep the program simple and gather details another way, such as a note on the order or a short follow-up form. This is weaker: the data doesn’t live on the registrant record and someone has to match it up. Use it for low-stakes cases, not for camps or anything involving children’s safety information.
Before you switch an active program
- Check for future events with sales. Decide whether those buyers keep their current terms. Usually they should.
- Update the website copy and confirmation emails. If registration is now required, buyers need to know before checkout, not after.
- Tell the front desk. A program that suddenly asks for names slows the line if staff don’t expect it.
- Review rosters and reports. Any report built on registrant data will look incomplete for the plain version. Note that in the report description so nobody chases missing data.
- Note the change date. A short internal record of when each version was in use saves confusion when someone looks at the numbers a year later.
Quick answers
Can I turn preregistration off for one event but keep it on for the rest of the program?
Not that we’d count on. Registration is generally a program-level choice. If one date needs different rules, putting that date on a separate program is the cleaner option.
Will removing registration delete existing registrant information?
Don’t assume either way. Test on a copy first, and export any rosters you need before making changes to a program that already has registrants.
Is there a setting I’m missing?
Possibly, depending on your version. Blackbaud support can tell you exactly what’s editable on a program with existing sales, and that’s worth a quick ticket before you rebuild anything.
