A list of 400 new contacts from a gala, a vendor file of corrected mailing addresses, or a spreadsheet from the education department that flags which teachers now work at different schools: sooner or later every Altru database needs data loaded in bulk. Typing it in by hand is slow and error-prone. Importing it carelessly is worse, because a bad import can create hundreds of duplicates or overwrite good addresses in a few minutes.
This guide covers how bulk constituent loads generally work in Altru, how to prepare a file so it lands cleanly, and the mistakes that cause the most cleanup afterward.
Two different jobs: adding people vs. changing people
Before you open a spreadsheet, decide which of these you are doing, because the file and the risks are different.
- Adding new constituents. The main risk is duplicates. Many of the people on a “new” list are already in Altru under a slightly different name or an older email address.
- Updating existing constituents. The main risk is overwriting. If the file is matched to the wrong record, or a blank column is treated as “clear this value,” you lose information that was correct.
Mixed files (some new, some existing) are common, and they are the ones that go wrong most often. If you can, split them before loading.
How bulk loading works in Altru
In Altru, bulk constituent work generally runs through import processes and batches. The usual pattern is: you map a file’s columns to Altru fields, the import brings rows into a batch, Altru validates them, you review and resolve exceptions, and only then do you commit the batch to live records. That review step before commit is your safety net, so do not skip it.
Which batch types and import options you see depends on your Altru setup and security rights. If you do not see an option for updating existing constituents, or you are unsure whether a given batch type will overwrite or append values, test it before using real data (see below) or ask Blackbaud support to confirm how it behaves in your database.
Prepare the file first
Most import problems are spreadsheet problems. A few minutes here saves hours later.
- Include the Altru lookup ID for every existing person. Matching on name alone is unreliable. If you are updating records, export the current lookup IDs with a query, then join them to your new data in the spreadsheet so each row points at exactly one constituent.
- Use one row per constituent. If a person appears twice, decide which row wins before you load, not after.
- Clean the formats. Split first and last names, trim stray spaces, use consistent state abbreviations and ZIP codes (watch for spreadsheets dropping leading zeros), and make phone numbers and dates follow one format.
- Match your code tables. Values such as address types, phone types, titles, and constituent codes need to match entries that already exist in Altru. A value that is spelled differently will either fail validation or, depending on settings, create a new table entry you did not want.
- Decide what blank means. For an update, remove columns you are not changing. Do not send a column of empty email cells and hope Altru ignores them.
Run a small test first
Take five to ten rows that represent the tricky cases: someone with an existing address, someone in a household, someone with two emails, someone brand new. Load just those. Then open each constituent record and check:
- Did the new address become primary, or get added as an extra address?
- Did the old email stay, get replaced, or get marked inactive?
- Did household relationships stay intact?
- Did anything you did not include in the file change?
Write the answers down. That short note becomes your organization’s import procedure for the next load.
Review exceptions before you commit
When the full batch validates, work through every exception rather than deleting the problem rows to get to a clean commit. Exceptions are often the most useful part of the process: they point to possible duplicates, invalid codes, and rows that matched nothing. Fix them in the batch or in your source file and re-import those rows.
For new-constituent loads, pay close attention to possible duplicate warnings. It is much easier to decide “this is the same person” during review than to merge two records with their own gifts, memberships, and ticket history later.
Check the results after commit
Do not assume the commit did what you meant. Build a quick query of the constituents you just touched (by the date they were changed, or by an attribute or constituent code you added for this load) and spot-check the output. Compare counts: if the file had 400 rows and the query shows 412 new constituents, something created extras.
Keep the original file, the mapped file, and the date of the load together in a shared folder. When someone asks six months from now why a group of addresses changed, you will have the answer.
Where Data Bridge fits
Data Bridge does not import into Altru; your imports and batches still happen there. What it does is sync Altru query results to tools like Google Sheets, which makes the before-and-after steps easier: you can keep a regularly synced sheet of current lookup IDs and contact details to build update files from, and keep a post-import check query in front of the people who need to review it without passing exports around. Learn more about Data Bridge.
Quick answers
Can I undo a committed batch?
Do not count on it. Treat commit as permanent, and if you need a rollback plan, export the affected fields with a query before you load so you can restore them.
Should I import directly into live records to save time?
No. The batch review step is where you catch duplicates and bad matches, and it costs far less time than cleanup.
