Say you need to flag 1,400 members as “Founding Circle,” or tag everyone who joined through a spring promotion, or mark the households that opted into a members-only newsletter. Opening each record and adding an attribute by hand is not a real option. You want to pick a group of members, choose an attribute, and apply it to all of them at once.
Whether Altru lets you do that cleanly depends on one question that is easy to skip: where should the attribute actually live? Answer that first and the rest gets much simpler.
Decide what you are tagging
“Membership” can mean three different things in Altru, and each behaves differently:
- The constituent (the person or household who holds the membership). Constituent attributes are the most widely used kind, and the tools for working with constituents in bulk are the most mature.
- The membership itself (the specific membership record with its level, term, and dates). Useful when the tag describes this particular term, such as “joined through spring promo.”
- The membership transaction or revenue (the join, renewal, or upgrade payment). Relevant if the tag describes how a sale happened, such as a campaign or channel.
A tag like “Founding Circle” is about the person and should survive lapses and rejoins, so it belongs on the constituent. A tag like “2026 spring promo” is about a single term and loses meaning once that term ends. Putting it on the constituent means it lingers after the member renews at a different level, which confuses anyone reading the record later.
Check what your Altru supports before planning around it
Honest caveat: attribute support and bulk-edit options vary by record type, and we would not promise you that a mass-add exists for every one of them. Before you design a process, confirm two things:
- Which record types you can define attribute categories for. Look at your attribute category setup and note which record types it offers. If membership is not one of them, the decision is made for you, and constituent attributes are the practical path.
- Which bulk tools your role can see. Depending on your security rights and configuration, you may have global change processes, import processes, or both. Ask your Altru administrator what is enabled, or check with Blackbaud support if you are not sure a given record type can be updated in bulk.
If you have a sandbox or test environment, run any bulk change there first. Without one, try it on a selection of five or ten records in production before you run it on the full group.
Build the group with a query, not a spreadsheet
However you apply the attribute, the list of who gets it should come from an Altru query, not a hand-built spreadsheet. A query is repeatable, auditable, and can be saved as a selection that bulk processes can use.
- Start from a membership query if your criteria are about level, program, dates, or status.
- Output the constituent ID (or membership ID, if you are tagging memberships) along with a few fields you can sanity-check: name, level, expiration date.
- Exclude anyone who already has the attribute so you don’t create duplicates.
- Save the results as a static selection when the group should be frozen at today’s date. Use a dynamic selection only if you really mean “whoever matches tomorrow too.”
Look at the count and spot-check a handful of rows before going further. Most bulk-tagging mistakes are query mistakes, not process mistakes.
Three ways to apply it
1. A global change against your selection
If your Altru has a global change that adds attributes for the record type you chose, this is the cleanest route: point it at the selection, set the category and value, and run it. Note the run date and selection name in your team’s change log so you can tell later where a batch of attributes came from.
2. An import
If no global change fits, export the IDs from your query, add columns for the attribute category, value, and any dates, then bring the file in through an import process that supports attributes for that record type. Imports take more care with field mapping, but they handle cases where different members need different attribute values.
3. Skip the attribute altogether
Sometimes an attribute is the wrong tool. If the tag can be worked out from data Altru already stores, such as membership level, join date, or how many consecutive years someone has renewed, a query or smart field can answer the question live, without a stored value that has to be kept up to date. Stored attributes go stale. Calculated criteria don’t.
Keep it from becoming a mess
- Use a code table value, not free text, for anything you plan to filter or report on. Spelling variations defeat queries.
- Add start and end dates if the attribute is time-bound, so reports can tell current tags from historical ones.
- Write down who owns the attribute and the rule for adding or removing it. An attribute nobody maintains is worse than none.
- Plan for new members. A one-time bulk add only covers the people who existed on the day you ran it. If new joiners should get the tag too, decide whether that happens on a schedule (re-run the query monthly, add anyone missing) or whether a calculated approach from option 3 fits better.
Quick answers
Can I remove the attributes in bulk if I get it wrong?
That depends on the bulk tools your configuration has, and delete options are not always the mirror image of add options. Assume cleanup could be manual, which is the best reason to test on a small selection first.
Should household members each get the attribute?
If your reports and mailings work at the household level, tag the household. If individual member cards or benefits depend on it, tag each person. Choose one and stick to it, because mixing the two makes counts unreliable.
