Short version: you can delete or retire the entries inside an Altru code table, but removing an entire code table is not something a typical Altru administrator can do from the application. Code tables sit underneath attributes, constituent fields, interactions, and other records, and Altru protects them because removing one could orphan data across the database.
That’s frustrating when you’ve inherited a database full of test tables, half-built attribute categories, and code tables nobody remembers creating. The good news is that you can get most of the practical benefit of deletion without deleting the table itself. Here’s how to think about it.
What a code table actually is in Altru
A code table is a reusable list of values: the options that show up in a drop-down. Some are built into Altru and power standard fields like constituent title, address type, or interaction category. Others get created by your own staff, most often as a side effect of setting up an attribute category whose value type is a code table.
That distinction matters:
- System code tables are part of the product. You can add, edit, and retire their entries, but the table is there to stay.
- Tables your organization created (usually through attributes) are the ones people want gone. Even these are tied to the attribute category and any records that hold values from them.
Cleaning up the entries
Most of the clutter people complain about lives in the entries, not the table, and that part is within your control.
- Find out whether an entry is in use. Build a query against the records that use the field (constituents, interactions, attributes, and so on) and filter on the value. If nothing comes back, the entry is a candidate for removal.
- Delete unused entries. Altru generally lets you delete an entry that no record references. If it refuses, that’s your sign the value is still attached to something.
- Mark in-use entries inactive. An inactive entry stops appearing as a choice for new data entry, but existing records keep their value and your history stays intact. For most cleanup work, this is the right move.
- Merge before you retire, when it makes sense. If “Corporate” and “Corporation” both exist, update the records on the wrong value to the right one (a batch or an import update is usually faster than editing by hand), then inactivate or delete the leftover.
When the whole table needs to go
If the problem is an entire table, usually one created for a project that never launched, work backward from what created it.
If it came from an attribute category
Check whether any constituent or other record has that attribute. If none do, look at whether the attribute category itself can be deleted. Removing an unused attribute category takes it off the screens staff actually see, which is the clutter they care about. Whether the underlying code table is cleaned up along with it isn’t something we’d promise; test it in a sandbox or ask Blackbaud support before assuming the table disappears.
If it’s in use or tied to the system
Leave it in place. Inactivate every entry you don’t want used, and, if your attribute category supports it, stop showing it to staff by adjusting how it’s used or by removing it from forms and processes where you control that. An empty, inactive table is invisible to most users.
If you truly need it removed
Open a case with Blackbaud support. Altru is a hosted product, so you don’t have direct database access, and anything beyond what the application allows has to go through them. Be specific: name the table, explain how it was created, and confirm whether any records reference it. Support can tell you whether removal is possible for your situation.
Before you delete anything
- Check queries, reports, and smart fields. Saved queries and smart fields often filter on specific code table values. Deleting a value can quietly change their results or break a filter.
- Check web forms and exports. If a value feeds a web form drop-down or an export to another tool, removing it can change what guests see or what lands downstream.
- Write down what you removed. A simple log of the table, entry, date, and reason saves someone a lot of guessing a year from now.
- Prefer inactive over deleted when in doubt. Inactivating is reversible. Deleting is not.
Keeping it from happening again
Code table sprawl usually comes from too many people having rights to create attributes and add entries on the fly. Limit who can create attribute categories, agree on naming conventions (no more “Test 2 – do not use”), and review code tables once a year alongside your other data hygiene. A short, clean list makes data entry faster and reporting more trustworthy, which is what you were after when you went looking for the delete button.
Quick answers
Can I delete a code table entry that’s already used on records?
Usually not. Reassign those records to a different value first, or mark the entry inactive so it stops appearing for new entries.
Does marking an entry inactive change existing records?
No. Records keep the value. It just won’t be offered as a choice going forward.
Is there any way to delete a system code table?
Not that we’re aware of, and you wouldn’t want to: standard Altru screens depend on them. Retire the entries you don’t use instead.
