“Can you pull a list of everything that’s reserved for next month?” sounds like a five-minute query. Then you open the ad-hoc query designer in Altru and realize “reserved” could mean three different things, each living in a different part of the database. Settle which one your colleague means first. Building the query is the easy part after that.
First, decide what “reserved” means to the person asking
In everyday museum language, a reserved event is anything with a name and a time slot attached before the visit. In Altru, that usually lands in one of these buckets:
- Scheduled program events with advance tickets. Timed admission, tours, shows, or classes where tickets were bought ahead of time through advance sales or the web. The ticket is tied to a specific event date and time.
- Group sales reservations. School groups, camps, and tour operators booked through group sales. These carry a reservation record with its own status, contact, itinerary, and balance due.
- Registrations for special events. Galas, member nights, and fundraisers managed as events with registrants rather than tickets.
Ask one clarifying question before you build anything: “Do you need tickets, groups, or registrants?” The education coordinator planning bus parking wants group reservations. Visitor services planning staffing wants advance ticket counts by time slot. Development wants registrants. Each answer points to a different query source.
Building the query
Pick the right source view
Start a new ad-hoc query and look through the available sources for the area you need: program events, sales orders or tickets, group sales reservations, or event registrants. Source names vary by Altru version and by which views your security role can see, so search or browse for terms like event, ticket, reservation, or registrant rather than expecting an exact name. If you can’t find a reservation-related source at all, check your role’s query permissions with your Altru administrator before you assume it doesn’t exist.
A useful habit: choose the source that matches the row you want back. If you want one row per event time slot, start from program events. If you want one row per booking, start from reservations or sales orders. Starting from the wrong level is the most common reason a query returns duplicated or inflated numbers.
Filter on the event date, not the sale date
“Reserved for next month” means the visit happens next month. Filter on the event or itinerary date, not the transaction or order date. Getting those two mixed up gives you a list of things sold next month, which looks plausible and is wrong.
If the query will be reused, use a relative date option (such as next month or the next 7 days) if your filter offers one, rather than hard-coded dates. That way it stays correct without anyone editing it.
Exclude what isn’t really reserved
- Cancelled and refunded items. Filter on status so cancelled reservations and refunded tickets drop out. Spot-check a couple of known cancellations to confirm they’re excluded.
- Tentative group bookings. Group reservations often move through statuses (tentative, confirmed, and so on). Decide with the requester whether tentative bookings belong on the list. For staffing, they usually do; for revenue, they usually don’t.
- Daily sales walk-ups. If the requester only wants pre-booked visits, make sure tickets sold at the door on the day aren’t mixed in.
Choose output fields people will actually use
Keep it short: event name, date, start time, quantity or headcount, status, and a contact (constituent name, email, or group leader). Add capacity alongside quantity sold if the goal is spotting sold-out or underbooked slots. Too many fields make a query slow and hard to read.
Check the numbers before you share them
Compare your query’s total for one date against what your daily sales or advance sales reports show for that same date. If the counts differ, the usual causes are a missing status filter, filtering on the wrong date, or a source that returns one row per ticket line instead of one row per order. Fix it now, before someone builds a staffing plan on it.
Once it checks out, save the query in a shared folder with a plain name, such as “Confirmed group reservations, next 30 days,” so nobody rebuilds it next quarter. If you need a total you’ll reuse across queries, a smart field may be worth setting up. Test it on a small date range first.
Video walkthrough
This short video covers querying reserved events in Altru.
Getting the list to the people who need it
A reserved-events query is often needed by people who never log into Altru: floor supervisors, educators, the café manager. Exporting to a spreadsheet every Monday works, but it’s a chore, and the copy goes stale by Wednesday. Data Bridge syncs an Altru query to Google Sheets and other tools, so the saved query you just built can feed a shared sheet without the weekly manual export.
Quick answers
Why does my query show more tickets than the event’s capacity?
The query is probably counting refunded or cancelled tickets, or returning duplicate rows because the source is at a lower level than you expected. Add a status filter and check which record each row represents.
Can one query cover both group reservations and individual advance tickets?
Sometimes, depending on which sources your version exposes, but it’s often cleaner to build two queries and combine the totals. If you aren’t sure, test it on a date where you know the real counts, or ask Blackbaud support.
