A digital membership card is only as good as the query behind it. If the query pulls the wrong expiration date, skips the second adult on a household membership, or still includes people who lapsed last spring, members get cards that are wrong. Front desk staff then have to sort it out with a line waiting behind them.
This guide covers how to plan and build an Altru query that feeds wallet cards cleanly: which query type to start from, what one row should represent, which fields to output, and the edge cases to test before you turn on automatic updates.
Decide what one row means before you open the query designer
This decision shapes every other choice in the build, and it is easy to skip. A wallet card belongs to a person, but in Altru a membership can cover several people. Before choosing fields, settle on one of these:
- One row per member (card holder). Every named person on a membership gets their own card. This is the usual choice for households and dual memberships, because each adult wants a card on their own phone.
- One row per membership. Only the primary member gets a card. It is simpler, but expect the second adult to ask why they don’t have one.
Whichever you pick, the row needs a stable, unique identifier that does not change at renewal. If that identifier changes every year, your card platform may issue a brand-new card instead of updating the existing one, and members end up with two passes in their wallet.
Start from a membership-based query
Build from a membership-oriented query source rather than a general constituent query. A membership source gives you program, level, status, and dates directly, and you can then reach out to the constituent for name and contact details. Starting from constituents and reaching into memberships tends to produce duplicate rows when someone has an old membership and a current one.
If you aren’t sure which query source in your Altru setup exposes individual members versus the membership itself, build a small test query against a household you know well and compare the row count to what you expect. It is a quick check and saves a lot of guessing.
The fields most card platforms need
Each wallet card provider defines its own required columns, so check their import spec first. In practice the list usually looks like this:
- Unique member identifier, the stable key described above.
- Barcode value. This must be whatever your scanners already recognize as a valid membership at the door. Confirm it with whoever manages admissions before going live, and scan a test card.
- First and last name as they should appear on the card.
- Email address, used to deliver the “add to wallet” link.
- Membership program and level, so the card can show the right tier and, often, a different design per level.
- Expiration date of the current term.
- Status, if the platform uses it to mark cards expired or inactive.
Keep column names and formats consistent once you go live. Renaming a column or changing the date format later is a common reason for a sync that quietly stops updating.
Filters that keep the list honest
Start narrow and widen only after testing:
- Include active memberships. Decide on purpose whether recently lapsed members stay in the feed so their card can flip to “expired,” or drop out entirely. Each card platform handles a missing row differently, so ask yours what happens.
- Think about renewals that are paid but not yet started. If a member renews early, you want the card to show the new expiration, not a status that briefly reads as expired.
- Exclude records with no email if your platform can’t deliver without one, but keep a separate list of them so staff can collect addresses at the desk.
- Exclude deceased constituents and anyone flagged as do-not-contact, in line with your organization’s communication rules.
Test with the records that usually break things
Before you schedule anything, pull a dozen known members and check each row by hand:
- A household or dual membership with two named adults
- A member who upgraded mid-term
- A gift membership where the purchaser and recipient are different people
- Someone who renewed early, and someone who renewed after lapsing
- A member with a duplicate constituent record
Duplicate records cause most of the surprises here. Two constituent records for one person can mean two cards, or a card tied to the record with the old email address. Cleaning duplicates before the first full send is far easier than recalling cards afterward.
Keeping it automatic
The point of the query is that nobody has to export a spreadsheet every Monday. Save it as a shared query, give it a clear name that says it feeds wallet cards, and add a note warning colleagues not to edit the output columns without checking with you first. Many accidental breaks come from someone adding a column for an unrelated report.
How the data actually reaches the card platform, whether through a direct connection, a scheduled export, or a sync tool, depends on the vendor. If you’re unsure what your Altru environment supports for scheduled or external access, ask Blackbaud support before you commit to a design.
Video walkthrough
The two videos below cover related setup for digital membership cards with Altru.
Where Social Good comes in
Social Good’s Digital Membership Cards provide Apple Wallet and Google Wallet membership cards for Altru members. The query planning above still applies: knowing what one row represents, which barcode your scanners read, and how renewals should appear makes any wallet card rollout go more smoothly.
Quick answers
Should second household members get their own card?
Usually yes. Build the query at the member level so each named adult has a row, and confirm each one has their own email address.
Will cards update when a member renews?
Only if the query reflects the new expiration and the unique identifier stays the same across renewals. Test with an early renewal before you go live.
