Altru keeps some constituencies up to date for you. When someone buys a membership, makes a gift, or is set up as a volunteer, the record tends to pick up the matching system constituency without anyone touching it. The labels you create yourself are a different story. “Teacher,” “Press,” “Corporate Partner,” “Docent,” “Field Trip Contact”: those are user-defined, and in most databases someone has to add and remove them by hand.
That’s why user-defined constituencies drift. A teacher who booked a school visit three years ago still carries the code. A board member’s spouse got it by accident. A new press contact never got it at all. This article covers what you can realistically automate, what you can’t, and how to set things up so the codes stay trustworthy.
The honest starting point
As far as we know, Altru doesn’t offer a rule engine that says “when X happens, add user-defined constituency Y.” System constituencies are driven by the underlying records (a membership, a gift, a volunteer record). User-defined ones are just labels with optional start and end dates, and nothing in the record tells Altru when to apply them.
Blackbaud does update Altru, so if this matters to your team, confirm the current behavior with Blackbaud support or test it in a sandbox before you build workarounds. Ask specifically whether constituencies can be added in bulk through import or another batch process in your version, because that answer shapes everything below.
First question: does it need to be a constituency?
Many user-defined constituencies are really just the answer to a query. “Field Trip Contact” usually means “this person booked a group or school visit in the last two years.” If that’s the definition, you don’t need a stored code at all. You need a saved query.
A query recalculates every time you run it, so it never goes stale. Some good candidates for replacing a static code with a query:
- Group and school contacts, based on group sales history.
- Lapsed members, based on membership expiration dates.
- Repeat visitors, based on ticket purchase history.
- Event attendees, based on registrations.
If you also want the value visible on the record or available in other queries, look at smart fields. They calculate a value from existing data on a schedule, which gets you close to “automatic” for anything that can be derived from transactions.
Keep true user-defined constituencies for relationships Altru can’t see in the data: press, vendors, elected officials, partner organizations, staff, and VIPs. Those labels need a human decision anyway.
For codes you keep, make the adding part reliable
Since the labels can’t apply themselves, the goal is to make adding them part of a routine instead of something people remember to do.
Tie each code to an owner and a trigger
Write down, for each user-defined constituency, who adds it and at what moment. “The group sales coordinator adds Field Trip Contact when a school booking is confirmed.” “Marketing adds Press when someone is added to the media list.” A code with no owner is a code that slowly rots.
Use a recurring exception query
This is the closest thing to automation most teams get. Build a query that finds records that should have the code but don’t. For example: constituents with a school group booking in the past year who don’t carry the Field Trip Contact constituency. Run it on a schedule (monthly works for most organizations) and work the list. Then build the reverse query: records that carry the code but no longer meet the definition.
Add in bulk where you can
If your Altru setup allows constituencies to be added through import or another batch process, the exception query becomes the input file. Export the IDs, add the constituency in one pass, and spot-check a handful of records afterward. If bulk adding isn’t available to you, the exception list still turns a vague cleanup project into a defined, finishable task.
Use dates so codes expire on their own
User-defined constituencies can carry a start and end date. This is the most underused part of the feature. If a teacher relationship is only meaningful for two school years, give the constituency an end date when you add it. Your queries can then filter to active constituencies only, and stale codes stop polluting your mailing lists even if nobody remembers to remove them.
The same goes for board terms, advisory committees, and annual sponsors. An end date set at the time of entry is far easier than a cleanup project later.
Clean up what’s already there
Before automating anything, look at the current state:
- List every user-defined constituency and how many records carry each one.
- Retire codes nobody can define or nobody uses. Fewer codes means fewer to maintain.
- For each remaining code, write a one-line definition and decide whether it should become a query instead.
- Check for duplicate constituent records. A person split across two records will look like they’re missing a code on one of them, which skews every exception list you build.
Quick answers
Can a web form purchase add a user-defined constituency?
We’re not aware of a native way to do this. Test it in a sandbox or ask Blackbaud support for your configuration. The dependable route is to identify those buyers by query afterward.
Should I end-date or delete old constituencies?
End-date them. That keeps the history (“was a docent from 2019 to 2023”) while keeping them out of current lists.
How often should the exception queries run?
Match it to how often the lists are used. If marketing pulls the Press list weekly, check it weekly. For most other codes, monthly is plenty.
