You pull a list of members for a renewal mailing or an event invite, and a handful of people show up as “Canceled” even though you can open their constituent record and see a perfectly good active membership. Or worse, they don’t show up at all because a filter for active members quietly dropped them. The data in Altru is usually fine. The problem is how the export is choosing which of a person’s memberships to show you.
The root cause: one person, several memberships
A constituent in Altru doesn’t have “a membership.” Over the years they can collect several: an old individual membership that was canceled when they upgraded, a family membership that lapsed, a gift membership someone bought for them, and the current active one. Each of those is a separate membership record tied to the same person or household.
When you build a query that starts from constituents and then add membership fields, you’re asking a one-to-many question: one constituent, many memberships. Altru has to do something with that. Depending on how the fields were added, you either get one row per membership (so the same person appears three times, one row canceled, one lapsed, one active), or the output collapses to a single value per person. When it collapses, the membership it lands on is not guaranteed to be the active one. A canceled record with a more recent change date, or one that simply sorts first, can win.
That’s why the symptom looks random. It only hits members with history, and it only shows up once someone de-duplicates the export by keeping the first row per person, or once a mail merge or spreadsheet lookup grabs the first match.
Other things that produce the same symptom
- Cancel-and-rebook upgrades. If staff handle upgrades or membership program changes by canceling the old membership and adding a new one, every upgraded member now has a canceled record sitting next to the active one.
- Duplicate constituents. The active membership is on one record and the canceled one is on a duplicate. Your export matches by email or name and picks the wrong person entirely.
- Household versus individual. In a household membership, the membership may live with the household or the primary member, while the secondary member’s own record carries an older canceled membership. Export the secondary member and you see the canceled one.
- Stale saved exports. An export or list built years ago may have been set up before your current membership programs existed, with filters or sorts that no longer match how you work.
How to fix the query
Start from memberships, not constituents
For anything that’s really a member list, build the query from the membership side. Each row is then one membership, and you can filter on membership status directly. Add the constituent’s name, address, and email as output fields from there. This one change resolves most of these cases because you’re never asking Altru to pick among a person’s memberships.
Filter on status explicitly
Put membership status equal to Active (and Pending, if your process uses it) in the criteria, not just in your head. If you also want people in a grace period after expiration, add that as a deliberate expiration-date condition rather than leaving status open.
If you must start from constituents
Put the membership status filter inside the same membership criteria block as the other membership fields, so the filter and the output fields refer to the same membership. If a constituent query mixes “has an active membership” in the criteria with a membership output field pulled independently, the criteria can pass on the active record while the output shows the canceled one. If you’re not sure how a particular field behaves, compare a few known members against their records before trusting the full export.
Consider a smart field for one-value-per-person needs
If you need a single “current membership level” on every constituent row, a smart field that’s defined around current membership can be easier to reason about than a raw membership field. Check how your smart field is defined and refreshed, and test it against members with upgrade history before relying on it.
Test with the people who break it
Don’t validate an export against a random sample. Pick five or six members you know have messy history: someone who upgraded mid-term, someone who lapsed and rejoined, a household secondary member, a gift recipient. Run the export and check each one against their record. If those come out right, the ordinary members will too.
While you’re at it, run a quick count: how many constituents have more than one membership record? That tells you how exposed every older query is. It’s also worth asking whether your upgrade process needs to create a canceled record at all. If you’re unsure whether Altru’s native upgrade path would keep history cleaner for your setup, try it in a sandbox or ask Blackbaud support before changing what the desk does.
Clean up the duplicates behind it
When the bad rows trace back to duplicate constituents, fixing the query only hides the problem. Merge the duplicates so the person has one record with their full membership history, and the export stops having to guess.
Keeping downstream lists correct
Once the query is right, the next risk is someone exporting an older version to a spreadsheet or email tool by hand. If your corrected member list feeds Google Sheets, Mailchimp, or ActiveCampaign, Data Bridge can sync that Altru query to those tools directly, so the destination always reflects the query you fixed rather than whichever CSV was downloaded last.
Quick answers
Why does the same member appear three times in my export?
The query returns one row per membership, and that person has three. Start from memberships and filter on active status, or remove membership fields you don’t need.
Is my membership data wrong?
Usually not. The active membership is there; the export is just showing a different one. Check the record directly to confirm before editing anything.
