Pull a list of everything you ran last spring and try to answer a simple question: how many of those events were school programs, how many were family weekends, and how many were adults-only evenings? In a lot of Altru databases, the honest answer is “let me go through them one by one.” The data is there, but nothing on the event itself says what kind of event it was.
This article covers where categorization actually lives in Altru, what’s missing at the event level, and a few setups that let you report and filter by event type without a lot of manual sorting.
Where Altru puts categories today
Altru organizes ticketed activity around programs, and a scheduled program owns its individual events (the specific dates and times people buy tickets for). Classification mostly happens at the program level. Programs can carry a category, and that category flows into reporting and into how programs are grouped for sales.
The gap shows up when one program contains events that aren’t really the same kind of thing. A “Planetarium Show” program might include a toddler session, a sensory-friendly session, and a late-night show for adults. They share a program, so they share its category, and Altru doesn’t give you a separate, built-in category or keyword field on each event to tell them apart.
Before you design around that, confirm what your own database supports. Field availability can change between releases and depends on what your organization has configured. Open a program and one of its events in a sandbox or test environment, check every tab, and if you’re unsure, ask Blackbaud support directly whether events support categories, attributes, or custom fields in your current version.
Decide what you’re actually trying to answer
“Tags” means different things to different departments, so pin it down before changing anything:
- Reporting: education wants attendance by audience (school, family, adult); finance wants revenue by program line.
- Staffing and operations: which events need a facilitator, which use a particular room, which are accessibility sessions.
- Marketing: who attended a given type of event, so you can invite them to the next one.
- Website filtering: letting visitors narrow a calendar to “kids” or “evenings.”
Each of these may land on a different workaround. One event can belong to several of these groups, which is the part a single category field never handles well.
Workarounds that hold up
1. Split programs along the line you report on most
If one distinction matters far more than the rest (say, school groups versus public sessions), make it a program boundary. “Planetarium: Public” and “Planetarium: School” as separate programs, each with its own category, gives you clean reporting with no extra fields. The cost is more programs to maintain and price, so do this only for the one or two splits that come up every month.
2. Use a strict event naming convention
Event names are searchable in queries. A consistent prefix or suffix turns the name into a lightweight tag:
- [SENSORY] Planetarium Morning Show
- [ADULT] Planetarium After Dark
- [FAMILY] Planetarium Saturday Matinee
Then build queries with “name contains [SENSORY]” filters. This works only if everyone who creates events follows the same list, spelled the same way. Keep the approved tags in a short shared document, and have one person review new events weekly until the habit sticks. Also check how event names display to the public on receipts, tickets, and web forms; if the bracketed tag looks odd to buyers, put it at the end or use a less obvious marker.
3. Lean on fields events already have
Location, resources, and staffing assignments already describe events in useful ways. If your “accessibility sessions” always use a specific room or require a specific resource, you may be able to report on that instead of inventing a new tag. It isn’t a perfect substitute, but it uses data your team already maintains.
4. Keep a mapping outside Altru for the rest
For multi-tag needs (an event that is both “family” and “STEM” and “free with admission”), a simple spreadsheet keyed on program and event name can hold the tags. Export your event or attendance query, join it to the spreadsheet, and pivot. It’s manual, but it’s honest about what the data model supports and doesn’t clutter Altru with conventions that only one department cares about.
Making the reports useful
Once a convention is in place, save it as shared queries so nobody rebuilds filters from scratch:
- One query per tag or category, returning event, date, capacity, tickets sold, and revenue.
- A constituent query of ticket buyers for each tag, for follow-up marketing.
- A quick audit query that lists recently created events missing an approved tag, so naming drift gets caught early.
Run the audit after each new season is built. That’s when inconsistent names creep in, usually from someone copying an older event and forgetting to update it.
Things to avoid
- Changing program categories midyear without noting it. Year-over-year reports will quietly shift, and someone will spend a day explaining a “drop” that’s really a reclassification.
- Too many tags. Five well-used tags beat twenty that nobody applies consistently.
- Tags that only live in one person’s head. Write down the list, what each means, and who owns it.
Quick answers
Can I add a category to an individual event in Altru?
Categories are generally set on the program, not each event. Check your version in a sandbox or with Blackbaud support to see if anything event-level is available to you.
Can an event have more than one tag?
Not natively as a keyword list. A naming convention can carry two or three markers, and an external spreadsheet can handle more.
