Every spring the camp director asks for the same thing: one spreadsheet with each camper’s name, age, session, T-shirt size, allergies, and who is allowed to pick them up. The registrations came in through an Altru web form, so the data is in Altru somewhere. Getting it out in a clean, camper-per-row layout is the hard part.
The good news is that you rarely need anything exotic. Camp registration exports almost always come down to one thing: building the right query against wherever your camp registrations actually land. The details depend on how your camp was set up in Altru, so start there.
Step one: find out what a “camp registration” is in your database
Organizations set up camps in Altru in a few different ways, and each one stores the data in a different place:
- As an event with registrants. Each camp week is an event, and each child is a registrant. This tends to be the easiest to report on, because registrants are tied to constituent records and the event itself.
- As a program or ticketed sale. Some sites sell camp the way they sell education programs or timed admission. The purchase is recorded as a sale, and the camper may or may not exist as their own constituent.
- As a workaround form. Occasionally camp was bolted onto a donation or membership-style form years ago because it was quick. These are the hardest to export, because camper details may live in comments, notes, or attributes rather than structured fields.
If you inherited the setup, open one recent registration from start to finish: the web form, the resulting transaction, and the constituent records it touched. Note where the child’s name went, where the parent’s name went, and where each answer to your extra questions ended up. Ten minutes of tracing saves hours of guessing at query sources.
Step two: build the query around the camper, not the payment
The most common mistake is starting from revenue. A revenue-based query gives you one row per payment, so a parent who registered three kids for two weeks shows up as a single line with a total. Camp staff need one row per camper per session.
Choose the query source that has one record per registrant (or per registration line, if camp is sold as a program), then add output fields like:
- Camper first and last name, and birth date or age if you collect it
- Session or week, with start date
- Parent or guardian name, email, and phone (often pulled through the household or a relationship)
- Answers to your registration questions: allergies, medications, T-shirt size, authorized pickups, photo permission
- Registration date and payment status, so you can spot unpaid or cancelled spots
Filter by event or program and by date range so next year’s query is a quick edit instead of a rebuild. Save it as an ad-hoc query with a clear name, and if several people will use it, keep it in a shared folder.
The custom questions are where it usually breaks
Standard fields like name and session are straightforward. The extra questions you added to the form are the part that trips people up. Depending on your setup, those answers may be stored as registration options, attributes, or free-text notes, and not every storage location is equally easy to pull into a query as clean columns.
We won’t pretend to know exactly how your form is configured. If you can’t find a query field that returns an answer you know was collected, check in a sandbox or test environment: submit a test registration with obvious answers (“TEST ALLERGY”), then search for that text in the query field list and on the records it created. If it’s still not reachable, Blackbaud support can tell you whether that data is available to queries for your form type. If it isn’t, it’s better to learn that before camp than the night before.
For next season, consider capturing anything staff need on a roster (allergies, pickup names, shirt size) in a structured field rather than an open comment box. It’s much easier to report on.
Exporting and handling the file
Once the query returns the right rows, export it to CSV or Excel. A few habits help:
- Sort before you hand it off. Sort by session, then last name, so counselors can find kids quickly.
- Make a separate medical version. Allergy and medication details are sensitive information about minors. Give the full list only to the people who need it, and send everyone else a roster without those columns.
- Date the file. Registrations keep coming in until the first day. Put the export date in the file name so nobody works from an old list.
- Rerun, don’t edit. If camp staff start typing corrections into the spreadsheet, the spreadsheet and Altru drift apart. Fix the record in Altru and run the query again.
Keeping the roster current without daily exports
That last point is the real pain during registration season. Someone has to rerun and resend the export every time a family signs up, swaps weeks, or cancels. If your camp team works from Google Sheets, Data Bridge can sync an Altru query to a sheet, so the roster stays tied to the same query you built above instead of being re-exported by hand. The query design work is the same either way; it just stops being a manual step.
Quick answers
Can I export straight from the web form itself?
Not in a way you’d want to rely on. The form collects the data; the records it creates are what you report on. Plan on querying those records.
Why do some campers show up twice?
Usually because a parent registered the same child as a new constituent on a second visit. Check for duplicate constituent records before camp starts, and merge them so medical notes and pickup names aren’t split across two people.
