Someone adds “Gift Shop – NEW” to a code table on a Tuesday afternoon. By Friday it shows up in three dropdowns, a report filter is quietly missing half the revenue it used to catch, and nobody remembers creating it. Code tables are small, but they feed queries, reports, web forms, and every dropdown your staff touches. Locking down who can change them is one of the cheapest data-quality wins in Altru.
The short version: Altru doesn’t control code table editing with a checkbox on each table. Access comes from the security layer, meaning the system roles assigned to each user, plus whether that user is flagged as a system administrator. Get those two things right and most of the problem goes away.
Start with your system administrators
This step gets skipped more than any other. A user marked as a system administrator generally gets past role-based restrictions. If half your staff have that flag “because it was easier during implementation,” no role you build will stop them from editing code tables.
- Pull a list of every application user and note who is a system administrator.
- For each one, ask: does this person actually need to change configuration, security, and setup? Usually that’s one or two people, plus a backup.
- Remove the flag from everyone else, and assign them a system role that covers their real job instead.
Do this carefully. Taking admin rights away from someone who has relied on them for years will surface every task they were quietly doing with that access. Plan the change for a slower stretch, and tell people ahead of time.
Build roles that leave code tables out
Once admin rights are trimmed, the system roles decide what everyone else can do. Code table maintenance lives with the administrative and setup features, separate from daily sales, memberships, and constituent work. A front desk or membership role normally has no reason to include it.
A practical pattern:
- Operational roles (front desk, membership, development, events) get the features for their daily work and nothing from the administration area.
- A data steward role for the one or two people who maintain code tables, attributes, and similar setup lists. This lets them do that job without full system administrator rights.
- System administrators stay a very short list.
I’m not certain how fine-grained the permissions go in your version of Altru. For example, whether you can let someone edit one specific code table but not others, or allow viewing code tables without editing. Don’t assume either way. Check the feature list when you edit a system role, and if the answer still isn’t clear, ask Blackbaud support before you design your roles around it.
Test with a real login, not a guess
Role permissions are easy to get wrong, because a user’s access is the combination of every role they hold. One leftover role from implementation can give back exactly what you meant to remove.
- Create a test user, or use a staff member’s login with their permission, and assign only the role you just built.
- Try to open and edit a code table. Then try the tasks that role should be able to do, to make sure you didn’t remove too much.
- Check every role assigned to real users, not only the main one. Remove any stray roles left over from setup.
If you have a sandbox or test environment, do the first round there. If you don’t, test in production with a low-stakes code table and undo any change you make.
Security is half the fix. The other half is a process
Locking editing down only helps if people have an easy way to ask for a new value. Otherwise they’ll type things into free-text fields or comments, and that’s worse.
- One place to ask. A shared inbox, a form, or a ticket queue. Ask for the value, which table it belongs in, and why the current options don’t fit.
- Naming rules. Decide on capitalization, abbreviations, and no “NEW,” “OLD,” or staff initials in entries. Write them down where the data steward can find them.
- Retire values, don’t delete them. Old entries are often tied to historical records. Marking a value inactive keeps history intact while removing it from dropdowns. Check how your code tables handle inactive entries before you clean anything up.
- A check after every change. When a value is added or renamed, look at which queries, smart fields, reports, and web forms filter on that table. A renamed entry can drop records out of a report without any error.
Clean up what’s already there
Once access is locked down, review each heavily used code table. Look for duplicates (“Volunteer” and “Volunteers”), test entries, and values no one recognizes. Before you merge or retire anything, run a query to see how many records use each value. Something that looks like junk may sit on thousands of constituent records.
Quick answers
Can I lock a single code table and leave the rest open?
Possibly, depending on what your system role features allow. Confirm in the role setup screens or with Blackbaud support rather than assuming.
Can I see who changed a code table entry?
Altru has some auditing ability, but what it records varies by area. If change history matters to you, ask Blackbaud support what’s tracked for code tables. Until then, keep a simple change log next to your naming rules.
