Notes tend to pile up outside Altru: a development officer’s spreadsheet of donor conversations, comments from an old ticketing or membership system, volunteer coordinator files, a legacy database you’re retiring. Sooner or later someone asks whether all of that can be attached to the right constituent records in one go instead of pasted in by hand.
The short answer is that it depends on what your Altru import options include, and on whether a “note” is really the right home for the information. Before you build a file, settle both of those questions. Getting them wrong is how organizations end up with thousands of notes nobody can report on.
First, decide whether these should be notes at all
Notes are free text attached to a constituent. They’re good for context a person will read on the record and hard to query, sort, or segment. Look at the data you’re holding and sort it before you import anything:
- Narrative context (“Prefers phone calls, lost spouse in 2024, interested in the conservation program”): a note is a reasonable fit.
- Something that happened on a date (a call, a meeting, a tour, a mailing): this is usually better recorded as an interaction or contact history, so it shows up in timelines and can be counted.
- A category or flag (“Board prospect,” “Do not solicit by mail,” “Founding member”): this belongs in an attribute or a constituent code, where queries and smart fields can use it. Buried in a note, it’s invisible to your mailing lists.
- Contact details (a second email, a seasonal address): these go in the proper address and email fields, not a note.
It’s common to find that only a fraction of a “notes” spreadsheet is actually notes. Split the file now; each piece will import differently.
Check what your Altru import area supports
Altru has an import area for bringing records in from files, and which import types appear there can vary with your configuration and the release you’re on. Look through the available import processes for anything that targets constituent notes directly. If you see one, open it and note which fields it expects: typically some combination of a constituent identifier, a note type, a date, a title, the note text, and an author.
If you don’t see a notes option, don’t assume it can’t be done, and don’t assume it can. Ask Blackbaud support plainly: “Can we bulk-import notes onto existing constituent records, and if so, through which import type?” They can also tell you whether a constituent update batch can carry note content in your environment. Get that answer before you spend hours formatting a file.
Prepare the file
Match on an ID, not a name
The single biggest source of bad note imports is matching on name. Two “Mary Smith” records, a household versus an individual, a maiden name in the old system: any of these can drop a sensitive note on the wrong person. Export your Altru constituents with their lookup IDs, match your notes file to that export, and import against the ID. Rows you can’t match confidently go into a separate pile for a person to review.
This is also a good moment to look for duplicate constituents. If the same person exists twice in Altru, decide which record survives before you attach notes, or you’ll split their history across both.
Clean the text
- Strip line breaks and stray characters that came out of the old system, or test how they display after import.
- Check for length. Very long notes may be truncated by a field limit; find out what the limit is before you lose the end of someone’s history.
- Remove anything that shouldn’t be in a CRM at all: card numbers, health details you have no reason to keep, staff opinions you wouldn’t want a donor to read.
Decide on note types and dates
Set up note types in Altru ahead of time if your import uses them, so imported notes can be told apart from ones staff enter later. Something like “Legacy system import” makes them easy to find and, if needed, clean up. Keep the original date from the source system where you have it; a note dated the day of the import loses most of its meaning.
Test small, then run it
- Import five to ten rows, ideally in a sandbox or test environment if you have one.
- Open each affected constituent record and confirm the note landed on the right person, with the right date, type, and complete text.
- Check how the notes display to the staff who’ll actually use them, such as membership or development.
- Run the full file only after the sample looks right, and keep the source file and the exception list somewhere you can find them later.
If bulk import isn’t available
You still have options short of retyping everything:
- Move structured pieces into attributes or other fields that do import, and keep only true narrative text for manual entry.
- Prioritize. Enter notes for active members, current donors, and open prospects first. Notes on someone who last visited a decade ago can stay in an archived file.
- Archive the rest with a pointer. Store the full legacy file securely and add a brief attribute or note on key records saying where the history lives.
- Ask Blackbaud about services. For a large conversion, they may be able to tell you whether a data-loading service is available for your account.
Quick answers
Can I import notes onto households instead of individuals?
Possibly, but confirm in a test first. Decide as a matter of policy whether context belongs to the household or the person, since staff will look in one place and not the other.
Can I undo a bad notes import?
Don’t count on an easy undo. That’s the main reason to use a distinct note type and test a small sample: if something goes wrong, you can at least find exactly which notes came from the import.
