Board, gala planning, collections, education advisory, the volunteer steering group. Every museum, zoo, or garden has a handful of committees, and sooner or later someone asks a simple question: “Who is on the development committee right now, and who rotated off last year?” If the answer lives in a spreadsheet on someone’s desktop, it will be out of date the day that person goes on vacation.
Altru doesn’t have a dedicated committee module that we’re aware of, but constituent attributes do the job well if you set them up with a little forethought. The design decisions you make on day one decide whether your rosters are easy to pull later or a mess of free text nobody trusts.
The basic setup: one attribute category, one code table
The cleanest approach is a single constituent attribute category, named something like Committee, whose data type is a code table. The code table holds one entry per committee: Board of Trustees, Finance Committee, Gala Committee, Collections Committee, and so on.
A few settings matter more than they look:
- Allow more than one value per constituent. People sit on several committees at once. If the category only allows one value, staff will overwrite memberships instead of adding them.
- Use the start and end dates. Attributes in Altru can carry dates. Treat the start date as the day someone joined and the end date as the day they left. That one habit turns the category from “who’s on it” into “who was on it, and when.”
- Keep the code table controlled. Limit who can add new code table entries. Otherwise you will end up with “Gala Cmte,” “Gala Committee 2025,” and “Gala” as three separate values.
If you are not sure how a particular attribute setting behaves in your version, try it in a sandbox or on a test constituent first, and check with Blackbaud support before rolling it out to everyone.
Where to put roles like chair, treasurer, or ex officio
This is the part worth deciding before anyone enters data. Attribute values don’t link to each other, so you can’t easily say “this person is chair of that specific committee” with two separate attribute rows. You have three realistic choices:
Option 1: Role in the comment field
Record the committee as the code table value and type the role (“Chair,” “Vice Chair”) in the attribute comment. It’s simple and keeps the code table short. The trade-off is that comments are free text, so querying for “all current chairs” depends on staff spelling it the same way every time. Publish a short list of allowed role words if you go this route.
Option 2: Combined values for leadership only
Keep plain committee entries for regular members, and add a few extra entries for officer seats, such as “Board of Trustees – Chair” or “Finance Committee – Treasurer.” Leadership becomes fully queryable, and the code table only grows by the number of officer seats you actually have. When someone moves from member to chair, end-date their member row and add a new chair row, so the history stays accurate.
Option 3: A second attribute category for role
A separate Committee Role category works if most people serve on only one committee. Once someone holds roles on two committees, you can’t tell which role belongs where, so we rarely recommend this unless your committees are small and don’t overlap.
For most organizations, Option 2 is the best balance: officers are reportable, and the code table stays manageable.
Keeping terms and history clean
Committees change every year, and the data only stays useful if departures get recorded as carefully as arrivals.
- Never delete a committee attribute when someone steps down. Add an end date. Deleting it erases the fact that they served, which matters for donor history, recognition, and the “past trustees” list someone will want for an anniversary event.
- Retire committees, don’t remove them. When a committee disbands, mark its code table entry inactive (if your setup allows it) rather than deleting it, so old records still display correctly.
- Do a once-a-year roster check. After your board elections or fiscal year turnover, pull each committee’s current list and send it to the staff liaison to confirm. It’s a small job, and it catches the people who quietly stopped attending two years ago.
Pulling rosters with queries
Once the data is structured, a constituent query does the rest. A useful starting set:
- Current roster for one committee: Committee attribute equals the committee, and end date is blank or in the future. Add name, preferred address, email, and phone as output fields.
- All current committee members: the same filter without picking a committee, with the attribute value in the output. Handy for invitations to volunteer or leadership events.
- Past members: end date is in the past. Good for “alumni” outreach and recognition lists.
- Giving by committee members: combine the committee filter with revenue fields to see who on the board has made a gift this fiscal year. Many boards track a “give or get” expectation, and this answers it without a separate spreadsheet.
Save these as shared queries with clear names so development, the executive office, and volunteer staff all pull from the same list. If a selection is built from them, you can also use it in marketing and communications to target mailings to committee members.
Attributes versus other options
You might be tempted to use constituent relationships, a household-style grouping, or a separate organization record called “Gala Committee” with members related to it. Those can work, but in our experience attributes are easier for front-line staff to maintain, easier to filter in queries, and less likely to be misread as an actual organization or household. Save relationships for real connections between people and organizations, like employers or spouses.
Whatever you choose, write a one-page guide covering the category name, which code table values exist, how to record roles, and the rule about end dates instead of deletions. The structure only works if everyone enters committee changes the same way.
