You ran the attendance report for last Saturday’s lecture series, and what you actually wanted was only the members, or only the people from a donor list, or only the attendees who also registered for the fall gala. The report gives you everyone. Here’s what you can and can’t narrow down inside the standard report, and the approach most administrators end up using instead.
Start with what the report already lets you choose
Altru’s standard event reports come with a fixed set of parameters, typically things like which event and which date or date range. Before you build anything new, open the report and look at every parameter on the screen, including any that are collapsed or optional. Run it once with each option changed so you can see exactly what it affects.
What you generally can’t do in a standard report is point it at your own list of people. There’s no reliable way to say “run this attendance report, but only for constituents in this selection.” If you see a parameter that looks like it does that in your version, test it against a small event where you know the answer before trusting it. If you’re unsure, Blackbaud support can confirm what the report’s parameters are meant to do.
The quick fix: export and filter
For a one-off question, the fastest route is to run the report as broadly as you need, export it to Excel or CSV, and filter there. This works well when the thing you want to filter on is already a column in the output, such as registration status or a ticket type.
It falls apart when the filter depends on information that isn’t in the report. Membership level, giving history, constituency codes, and “attended event A but not event B” all live elsewhere in Altru. You’d end up exporting a second list and matching names in a spreadsheet, which is slow and error-prone when two people share a name.
The better fix: rebuild the report as a query
When you need real filtering, an ad-hoc query is the tool. Instead of asking the report to filter, you build your own attendance list with the criteria you want.
- Pick an event-based source view. In the query source list, look for the source that covers event registrants or attendees. Names differ a little between versions, so if you don’t see an obvious one, check with whoever built your organization’s existing event queries or ask Blackbaud support.
- Filter on the event. Add the event name or event date as your first filter so the results match what the report would show.
- Add the attendance condition. Include the field that indicates whether the registrant attended, if your event setup records it. If your staff don’t mark attendance consistently, the query will only be as accurate as that data, so check a known event first.
- Bring in the constituent fields you care about. From the registrant, you can usually reach the constituent record and add filters for membership, constituency, address, or giving information.
- Filter by selection if you have a list. This is the piece the standard report doesn’t give you. Most query designs let you filter on whether the constituent is in an existing selection. Use that to limit results to your board members, a donor segment, or anyone on a list you’ve already built.
- Choose your output columns and save. Match the columns your team expects from the report so the switch feels familiar.
Once the query works, save it as a selection too. That gives you a reusable “attended this event” list you can use in other queries, mailings, or a follow-up filter.
Comparing two events
For “came to the spring talk but didn’t register for the fall one,” build a selection of fall registrants first. Then run the spring attendee query with a filter that excludes constituents in that selection. Two small, clear steps are easier to check than one complicated query.
Things that trip people up
- Households and guests. Attendance may be tied to a registrant and their guests differently. Decide whether you’re counting people or registrations, and check a few records by hand.
- Duplicate records. If one person has two constituent records, a selection-based filter may miss them. Clean duplicates before you rely on the numbers for anything important.
- Totals that don’t match the report. Some reports apply their own logic for cancellations or no-shows. If your query count differs, compare a single event line by line until you find the rule.
- Permissions. Staff who can run the report may not have rights to build or run queries on that source. Sort that out before you hand off the new process.
Getting the filtered list to the people who use it
Often the person asking for a filtered attendance list isn’t the Altru admin. It’s education staff planning follow-up, or development staff checking which donors showed up. Running the query and emailing an export each week works, but the list is stale the moment it’s sent.
If that becomes a routine request, Data Bridge can sync an Altru query to Google Sheets, Mailchimp, ActiveCampaign, and other tools. Build the filtered attendance query once in Altru and colleagues can work from the synced list without a manual export each time.
Quick answers
Can I add my own filters to the standard event attendance report?
Not beyond the parameters it ships with. For custom criteria, especially filtering by a selection, build an ad-hoc query instead.
Will a query give the same numbers as the report?
It should be close, but reports may handle cancellations or guests in their own way. Check one event side by side before you switch over.
