A seasonal cashier needs to sell tickets and look up a member. They don’t need to refund a donation, merge constituents, or edit a membership program’s pricing. Yet in a lot of Altru databases, that cashier ends up with a role far broader than the job, usually because the closest prebuilt role was “close enough” and nobody had time to build a better one.
Custom system roles fix that. They take some patience to build, and Altru’s permission model is more granular in some places than others. This guide covers how to plan a role, how to build and test it, and what to do when the permissions you want don’t quite exist.
How Altru permissions are organized
Altru security is role-based. A system role is a bundle of permissions, and each user is assigned one or more roles. A user’s effective access comes from every role they hold, so in general, permissions add up. Keep that in mind: if someone has a tight front-desk role plus a broad finance role, they will usually be able to do what the broad role allows. If your roles use explicit deny settings, check how your version resolves a grant in one role against a deny in another before relying on it.
Inside a role, permissions are granted to individual features: the pages, forms, tasks, data lists, queries, and reports that make up the application. That is where the granularity lives. It’s also where the work is, because a single business task (say, “process a membership renewal”) usually touches several features at once.
There is also usually an administrator or supervisor-level setting that bypasses role permissions entirely. Reserve it for the one or two people who truly administer the database. Every other user should get access through roles.
Plan the role before you open Altru
Most role problems come from starting in the permission screens. Start on paper instead.
- Describe the job, not the person. “Front desk, admissions only,” “Membership coordinator,” “Development associate, gifts but no refunds.” Roles named after people stop making sense the day that person leaves.
- List the tasks the job requires. Daily sales, member lookup, advance sales, group sales, constituent edits, gift entry, batches, running specific queries or reports.
- List what the job must never do. Refunds, voids, deleting records, merging duplicates, changing prices or program setup, exporting constituent data. This “never” list matters as much as the “do” list, and it’s what you’ll test against.
- Decide how many roles you actually need. Small teams often do well with five or six roles. Dozens of one-off roles become impossible to audit.
Build the role
Altru’s security settings live in the administration area, and only users with admin rights can create or edit roles. The general approach:
- Copy, don’t edit, the prebuilt roles. If your version lets you copy an existing role, start from the closest one and trim it down. If you edit a prebuilt role directly, you lose your reference point and may change access for everyone who already holds it.
- Grant by feature area. Work through the areas the job touches (sales, memberships, constituents, revenue) and grant what the task list requires. Leave everything else ungranted.
- Check related features together. A form to add a record often has separate permissions from the form to edit or delete it, and a page may display a data list that has its own permission. If a user can open a record but sees empty sections, a related data list is usually what’s missing.
- Handle queries and reports deliberately. Query access is a common blind spot. A user who can build ad hoc queries across constituents can often see and export far more than their screens show them. Give lower-level roles specific saved queries and reports rather than broad query-building rights, and confirm in testing how your version handles this.
- Document the role. Keep a short note, in the role description or a shared doc, explaining what the role is for and any non-obvious permissions you added.
Test it like a skeptic
Create a test user (or use a sandbox if you have one), assign only the new role, and log in as that user. Walk through every task on the “do” list from start to finish, including printing or emailing a receipt if the job needs that. Then try every item on the “never” list. Anything on the “never” list that works is a bug in the role.
Expect a few rounds. The first version is almost always missing a permission or two that only shows up in the middle of a real transaction. Test before go-live, not during a school-group rush.
When the permission you want doesn’t exist
This is the honest part. Altru doesn’t split every action into its own permission. Sometimes a single feature bundles something you want to allow with something you don’t, such as editing a record and changing a sensitive field on it. A few ways to handle those gaps:
- Confirm before you assume. Check Blackbaud’s documentation or ask Blackbaud support whether a narrower permission exists for that action. Test in a sandbox before changing a live role.
- Move the sensitive step to a different person. If refunds can’t be separated cleanly, give refund access only to supervisors and route those requests to them.
- Audit after the fact. Where you can’t prevent an action, review it. A saved query on recent refunds, voids, or record changes, run weekly by a manager, catches mistakes and misuse.
- Accept the trade-off openly. Sometimes the right answer is a slightly broader role plus training and review. Write that decision down so the next administrator understands why.
Keep roles from drifting
Roles decay. Someone gets a permission “just for this weekend” and keeps it for three years. Twice a year, export or review the list of users and their roles, disable accounts for staff who have left, and remove temporary roles. When the job changes, update the role. Don’t stack another role on top of the old one.
Quick answers
Can one user hold multiple roles?
Yes, and their access reflects all of them together. That’s useful for people with mixed jobs, but test the combined access with a test user rather than assuming.
Will changing a role affect users who already have it?
Yes. Role changes apply to everyone assigned that role, which is another reason to copy rather than edit prebuilt roles.
