Open a few constituent records in an older Altru database and you’ll usually find the same thing: a dozen notes, all typed “General,” some saying “called about parking,” others recording that a donor never wants a phone call again. The information is there. Nobody can find it, sort it, or pull it into a list.
Note types fix that, but only if you set them up with some intent. Adding the values takes a few minutes. Deciding what they should be is the real work, and it’s worth doing before staff start using them.
Where note types live
In Altru, the choices that appear in the note type dropdown on a constituent note come from a code table, the same kind of administrator-maintained list that drives many other dropdowns in the system. You’ll find code tables in the Administration area; searching the code table list for “note” is usually the quickest way to the right one. If you don’t see it, or you can’t edit it, your security role probably doesn’t include code table maintenance, and someone with administrator rights will need to make the change or grant access.
From there, the mechanics are simple: add an entry, give it a clear name, save. The new value shows up in the dropdown the next time someone adds a note. Because exact screens can vary by release and by how your database was configured, try your first change in a sandbox or on a slow afternoon and confirm it appears where you expect.
Decide what a note is for before you add types
Altru gives you several places to put information about a person, and note types work best when they don’t overlap with the others:
- Notes are for narrative context: what happened, what was said, why a decision was made.
- Interactions are better for contacts you want to count or report on, such as calls, meetings, and visits with a date and a staff member attached.
- Attributes are better for a single fact you’ll filter on often, like “prefers no phone calls” or “board member.”
- Solicit codes and communication preferences are where contact restrictions should actually be enforced. A note that says “do not mail” won’t stop an appeal; a solicit code can.
If a proposed note type is really a yes/no flag, it probably belongs as an attribute. If it’s really a contact you’ll want to count by month, it’s probably an interaction. Keeping notes for the stories behind the data makes the note type list shorter and more useful.
A starting list that holds up
There’s no single correct set, but a list of eight to twelve types tends to cover a museum, zoo, or garden without becoming a scrolling exercise. Something along these lines:
- Membership – renewal conversations, card issues, upgrade or downgrade reasons
- Development – gift conversations, stewardship context, cultivation history
- Guest services – complaints, comp tickets given, visit issues
- Group sales – school or tour group history and preferences
- Data maintenance – merges, address corrections, why a record was changed
- Payment / billing – refunds, disputes, declined cards
- Volunteer – if volunteers are tracked in Altru at all
- Sensitive – deceased family members, personal circumstances, anything staff should handle carefully
Name types by department or purpose, not by person. “Sarah’s notes” becomes meaningless the day Sarah leaves.
Be careful with sensitive information
Before creating a “Sensitive” or “Confidential” type, check what your security roles actually restrict. A note type label does not, by itself, hide a note from anyone. If certain notes should only be visible to development staff, confirm with Blackbaud support or your own testing whether your role configuration can enforce that. If it can’t, the safer rule is simple: don’t put it in a note.
Cleaning up the old “General” pile
Adding new types doesn’t recategorize anything already in the database. You have a few options:
- Leave history alone and apply the new types going forward. This is fine for most organizations, and it’s the cheapest option.
- Reclassify high-value records by hand, such as major donors or long-time members, where the context really matters.
- Run a constituent query filtered on note type to see how many “General” notes exist and who wrote them. That number tells you whether a cleanup project is realistic.
If you retire a type, mark it inactive rather than deleting it. Code table values in use generally can’t be removed cleanly, and inactivating keeps old notes intact while removing the option from the dropdown.
Make it stick with staff
The list only works if people pick the right type. A few habits help:
- Write a one-line definition for each type and share it in your staff guide. “Guest services: anything a visitor complained about or was compensated for.”
- Ask staff to start the note title with a short summary, so a list of notes reads like a timeline.
- Review a sample of new notes after the first month. You’ll quickly see which types are confusing or unused.
- Resist adding a new type every time someone asks. Each one makes the dropdown longer for everyone.
Quick answers
Can I require a note type when a note is saved?
Whether the field is required depends on your Altru configuration and release. Test by trying to save a note without one in your environment; if it saves, plan on training rather than enforcement.
Can I report on notes by type?
Constituent queries can typically filter and output note fields, including type. Build a small test query first to confirm which note fields are available in your database before promising a report to anyone.
