Two members open their wallet passes and see the same ID. Or a member renews and their card shows the old expiration because the update landed on someone else’s pass. Or a pass refuses to update at all because the sync can’t tell which record it belongs to. When a digital card provider like Cuseum is fed from Altru, these are usually symptoms of one problem: the identifier the card uses to find a member is not unique in the data you’re sending.
The good news is that this is almost always a data and mapping issue, not something broken in either system. You can track it down from the Altru side.
First, figure out which “lookup ID” the cards use
Altru has more than one kind of identifier, and they behave differently:
- Constituent lookup ID identifies a person (or organization) record. It is meant to be one per constituent.
- Membership identifiers belong to the membership itself. In a household or dual membership, several people can sit under one membership, so anything tied to the membership can legitimately repeat across members.
- Member card numbers are tied to the cards issued under a membership, and depending on how your programs are set up, may or may not be unique per person.
Before changing anything, confirm with Cuseum exactly which field from your Altru export or integration they treat as the unique key for a pass. Then look at your own export query and confirm which Altru field actually populates it. A surprising number of duplicate problems come from a column labeled “Lookup ID” that is really pulling a membership-level value.
The four usual causes
1. A membership-level field is being used as a person-level key
If the card key comes from the membership, every member in a two-adult household shares it. The first person’s pass works and the second overwrites it, or both passes flip back and forth on each update. The fix is to key cards on something that is unique per cardholder, typically the constituent lookup ID or a per-member card number, and to have Cuseum re-map accordingly.
2. The same person exists twice in Altru
A member who bought online with a work email and later renewed at the desk with a personal one can end up as two constituents. Each has its own lookup ID, so this shows up less as a “duplicate ID” and more as two passes for one person, or a pass attached to the stale record that never gets the renewal. These need to be merged in Altru, not patched in the card platform.
3. The export query returns repeated rows
Queries that join constituents to memberships, addresses, or emails can return one row per address or per email. If a member has two email addresses on file, the same lookup ID appears twice in the output. Check your query’s output fields and filters: limit to primary email and primary address, and filter to active memberships so lapsed history rows don’t come along too.
4. Manual imports or edits reused an ID
If lookup IDs were ever set by hand, during a data conversion or a bulk import, two records may have been given the same value or a value that collides with another system. Whether Altru blocks a duplicate in your specific setup is worth testing in a sandbox rather than assuming; either way, you want to find any that slipped through.
How to find the duplicates
- Export exactly what the card provider receives. Run the same query or file that feeds Cuseum, not a similar one.
- Count each key value. In a spreadsheet, sort by the key column and use a count formula or pivot table to show any value that appears more than once.
- Sort the repeats into causes. Same person on both rows means a query join problem. Different people in one household means a membership-level key. Same person name with different IDs elsewhere in the file means duplicate constituents.
- Look for near-duplicates too. Search the file for repeated email addresses and repeated name-plus-postal-code combinations. Those point to duplicate constituents that won’t show up as a repeated ID.
Cleaning it up without breaking existing passes
Order matters here, because members already have passes on their phones.
- Talk to Cuseum before re-keying. Changing the field their system uses as the identifier may orphan passes that are already installed. Ask how they handle a key change and whether members will need a new pass link.
- Merge duplicate constituents in Altru first. Decide which record survives (usually the one holding the current membership), merge, and only then re-run the export.
- Fix the query, then re-test. Re-run the count check from above. The file should have zero repeated keys before it goes back to the provider.
- Reissue only the affected cards. Contact the specific members whose passes were wrong rather than sending a new card link to everyone.
Keeping it from coming back
Once the key is right, new duplicates mostly come from new duplicate constituents: online buyers who don’t match an existing record, desk staff creating a new record instead of searching first, and imported lists. A short desk rule (search by email and phone before adding anyone) helps. So does running the same repeated-key check on a schedule, such as monthly or before each renewal mailing, so you catch problems before members do.
Where Social Good can help
The mapping and query fixes above are yours to make in Altru and with your card provider. For the duplicate constituent side, our Deduper finds and helps fix duplicate constituent and email records in Altru, which removes one of the most common sources of mismatched or doubled membership cards.
Quick answers
Should household members share one pass?
That’s a policy choice, but most organizations want one pass per named cardholder so each person can be scanned and verified. That requires a per-person key.
Can I just edit the lookup ID on one of the records?
Possibly, but other systems, reports, and integrations may already reference it. Check what else uses that ID before changing it, and test in a sandbox if you can.
