On a holiday Monday you might have twenty people logged into Altru at once: admissions cashiers, a membership table by the entrance, a group sales coordinator checking in buses, a supervisor handling refunds, and a few volunteers who were added last Thursday. Keeping track of who should be able to do what, and who sold what, gets hard fast. The natural wish is to sort users into groups by area (Admissions, Membership, Groups, Retail) and manage each group as one unit.
Altru doesn’t give you a “department” or “team” container for users in the way some systems do. What it does give you is security roles, and with a little planning those roles can do most of the work of grouping people by function. Here’s how to set that up, where it falls short, and what to do about the gaps.
Use roles as your groups
In Altru, what a user can see and do comes from the security roles assigned to them. A user can hold more than one role. That makes roles the closest thing Altru has to a group: if every admissions cashier holds the same role, changing that role changes what all of them can do.
The trick is to design roles around stations and functions, not around individual people or job titles. A sensible starting set for a busy admission day looks like this:
- Admissions – Sales: daily sales, ticket lookups, basic constituent search. No refunds, no editing prices.
- Admissions – Lead: everything in Sales, plus refunds, exchanges, and voids.
- Membership Desk: selling and renewing memberships, looking up and updating constituent and household records.
- Group Sales: group reservations, advance sales, and payments against existing orders.
- Volunteer / Temporary: the narrowest role you can build, often just daily sales for one or two items.
Keep administrative and finance roles separate. Nobody working a register on your busiest day needs access to batches, configuration, or security settings.
Name roles so the grouping is obvious
Since there’s no folder or team label, the role name is your grouping. Use a consistent prefix such as “ADM -“, “MEM -“, “GRP -“, and “TEMP -” so the list sorts by area and anyone auditing it can tell at a glance which function a role belongs to. Write a one-line description on each role saying who it’s for.
Plan the peak-day roster ahead of time
Role design only helps if the right people are in the right roles before the doors open. A week or two before a known high-attendance day:
- List every station you’ll staff and which role each needs.
- Map each person to a station. Floaters who move between admissions and membership can hold both roles; don’t create a one-off combined role for them.
- Create accounts for temporary staff early and have each person log in once before the event. Password resets and forgotten usernames are much easier to fix on a Tuesday afternoon.
- Give every person their own login. Shared “frontdesk1” accounts make the day feel simpler but leave you unable to tell who processed a refund or which drawer is short.
- Test each role by signing in as a test user who holds only that role. Confirm the screens and tasks they need are there, and the ones they shouldn’t touch are not.
Afterward, remove temporary roles or deactivate the accounts. Keep a short checklist so this cleanup actually happens.
Grouping for reporting and reconciliation
The other reason people want user groups is reporting: “How much did the membership table sell?” or “Which admissions drawer is off?” Because Altru records who processed each transaction, you can usually answer this by user, then roll users up into areas yourself.
- Keep a simple list (a spreadsheet is fine) mapping each user to their area for the day.
- Run your sales or revenue reports or queries by user, then group the results by area using that list.
- If staff stay in the same area all season, this mapping rarely changes and becomes a reusable template.
How cleanly this works depends on which reports and query fields your Altru instance exposes for the processing user. Before relying on it for a big day, run a test on a normal day’s data and make sure the numbers tie out to your cash and card totals.
Where roles fall short
Being honest about the limits helps you plan around them:
- Roles control permissions, not membership in a team. There isn’t an obvious native way to say “these twelve people are Admissions” separate from what they’re allowed to do. If a role is shared by two areas, you can’t use it to tell them apart.
- Bulk changes may be manual. Adding or removing a role for many users at once can be tedious. Check with Blackbaud support whether your version offers a faster method before you plan a large roster change.
- Role sprawl is real. It’s tempting to create a new role every time someone needs one extra permission. Over a few seasons that leaves you with dozens of near-duplicates nobody understands. Review roles once a year and merge where you can.
If you’re unsure whether a particular permission sits where you think it does, set it up in a sandbox or test environment first, or ask Blackbaud support. Finding out mid-shift that the membership desk can’t renew a lapsed member is the scenario you’re trying to avoid.
Quick answers
Can a user belong to more than one area?
Yes. Assign them each role they need. Their permissions are the combination of all their roles.
Should volunteers get their own role?
Usually, yes. A dedicated, narrow role makes it easy to see who has temporary access and to remove it when the event is over.
Is it worth creating roles per event?
Rarely. Build roles per function and reuse them. Change who holds them for each event, not the roles themselves.
