Altru uses the word “event” for two quite different things. A program event is a scheduled occurrence of something you sell tickets to, like a summer camp session, a guided tour, or a planetarium show, and it’s sold through daily sales, advance sales, or group sales. A special event is a gala, a members’ preview night, or a fundraising dinner, with registration options, invitations, and guest lists. They share a word, but they don’t share an audience, and they almost never share a follow-up plan.
That difference shows up when you build a query. You want “everyone who registered for spring camp” or “everyone coming to the gala,” and the source view you start from either blends the two groups or doesn’t line up cleanly with one of them. Below is how to get two clean, reusable lists anyway, plus how to check what your own Altru database offers before you build anything.
Start by testing what your source views actually return
Don’t trust the name of a source view. Before you design anything, run a small test:
- Pick one constituent you know registered for a recent program event and one you know registered for a recent special event.
- Open a new ad-hoc query and search the source view list for terms like “registrant,” “event,” “program,” “ticket,” and “sales order.” Note every candidate.
- For each candidate, filter to those two constituents and see which registrations come back.
- Open the field list and look for anything that tells the two apart: an event type or category, a program name, a link to a program, a registration option, a sales method.
Fifteen minutes of this tells you more than any documentation. Available views and fields can differ by release and by what your security role allows, so if you can’t find a view you expected, ask your Altru administrator or Blackbaud support whether it exists and whether your role has access to it.
If a distinguishing field exists: build two saved queries
This is the easy case. Build one query, then copy it:
- Program event registrants: filter on the field that marks an event as tied to a program. If there is a program field, “is not blank” is often the cleanest filter.
- Special event registrants: the same query with the opposite filter, or a filter on your special event categories.
Then save each one as a selection. Selections are what make this worth doing. Once “Special event registrants – current fiscal year” exists, you can drop it into other queries, exports, and marketing lists without rebuilding the logic each time. Give both queries plain names, keep them in a shared folder, and put the filter logic in the description so the next admin knows why they work.
If nothing distinguishes them: start from a different place
Sometimes the registrant-style view doesn’t give you a reliable field to split on. Two approaches tend to work better than fighting it:
For program events, think in sales, not registrations
Program event attendance in Altru is mostly a ticketing story. Starting from sales orders or tickets and filtering by program or program event usually gives you the right people. One caveat: depending on how you sell, the only named person may be the purchaser, not every child in the camp group or every adult on the tour. If your follow-up needs the actual attendees, check whether you capture them by name, and whether that data lives somewhere a query can reach.
For special events, start from the event itself
Special events carry their own registrant and guest structure. Starting from a special event view, or from constituents with a filter on related event registrations, and limiting to specific special events or a date range usually keeps program activity out entirely.
Make the split easier upstream
Query filters are only as good as the data entry behind them. A few habits help a lot:
- Use event categories consistently for special events, and agree on a short list. “Gala,” “Member event,” “Donor cultivation” is enough for most organizations.
- Adopt a naming convention. Prefixing special event names (for example, “SE –”) is crude, but a “begins with” filter on a name is easy to explain to anyone.
- Don’t build fundraising events as programs just because selling tickets is easier that way. It’s the most common reason the two groups end up blended, and it also muddies your revenue reporting.
- Write down which tool to use for which kind of event, so new staff don’t guess.
Check permissions while you’re at it
Query access in Altru follows security roles. Your development team may need special event guest lists while your education team only needs camp rosters. Once you’ve built two separate saved queries and selections, you can share each one with the right people instead of handing everyone a broad registrant view that exposes more than they need.
Quick answers
Can I create a brand-new source view in Altru?
Not in the way you’d create a query. Source views are part of the application. If you truly need a view that doesn’t exist, raise it with Blackbaud support. In practice, saved queries and selections built on existing views cover most needs.
Why do my registrant counts not match ticket counts?
Usually because one list counts named registrants and the other counts tickets or orders. Decide which number answers your question before comparing them.
Should I test these queries before using them in mailings?
Yes. Spot-check a handful of known records in each list, especially anyone who attended both a program and a special event recently, before using either list for outreach.
