Your front desk sells tickets all day. Then a member walks up, says they moved, and wants their address fixed and their card reprinted. Or they want to upgrade from Individual to Family before they go in. The cashier can’t do it, so they flag down a supervisor, and the line stops.
The usual quick fix is to give a few trusted cashiers a broader role, or just make them a membership manager. That works until someone accidentally voids a batch or opens a donor’s giving history they had no reason to see. A better answer is a custom role that sits in between: everything a ticket seller does, plus a narrow slice of membership editing. Here’s how to think about building one in Altru, and where to be careful.
How Altru security works, briefly
Altru controls access through system roles. A role is a bundle of permissions to features, tasks, pages, and reports. Each application user is assigned one or more roles, and their effective access is the combination of everything those roles grant. That last point matters: roles add up. If a cashier already has a ticket-selling role, you don’t have to rebuild ticketing access in the new role. You can create a small “membership edits” role and assign it alongside the existing one.
That gives you two reasonable designs:
- One combined role (for example, “Advanced Ticket Seller”) that contains all ticket-selling permissions plus selected membership permissions. Easier to explain, easier to assign to a new hire.
- A stacked add-on role (for example, “Desk Membership Edits”) that you give only to the cashiers who need it, on top of their normal ticket-selling role. Easier to maintain, because ticketing changes only need to happen in one place.
Either works. Stacking is usually cleaner if you have more than a handful of desk staff.
Building the role
- Start from what already works. Look at the role your cashiers use today and list what it covers: daily sales, advance sales, refunds or exchanges if you allow them, constituent lookup. If Altru lets you copy that role in your database, copy it rather than starting blank; otherwise, note its permissions so you can recreate them.
- Decide exactly which membership actions the desk should handle. Write them down before you touch security. A typical list: view membership details, update contact information, add or change members on a household membership, reprint a card, and process an upgrade or renewal as a sale. A typical “not on this list”: changing expiration dates by hand, deleting memberships, editing membership programs or pricing, and anything involving batches.
- Grant permissions one feature at a time. In the role, add the membership and constituent features that match your list. Resist granting a whole functional area just because it’s faster. Broad grants are how cashiers end up seeing revenue history or marketing data.
- Assign it to a test user first. Create or borrow an application user, give them only the new role (plus the base ticket role if you’re stacking), and log in as them.
- Test the real desk scenarios. Sell a timed ticket. Look up a member. Change an address. Add a child to a family membership. Upgrade a membership at the register. Then try a few things they shouldn’t be able to do, like editing a program or opening a donor’s revenue, and confirm they’re blocked.
- Roll out to a small group. Give it to two or three experienced cashiers for a week before assigning it broadly. They’ll find the gaps faster than any test plan.
Where it gets tricky
Permissions don’t always split the way you want
Some membership actions may be bundled with others, so granting “edit” on one screen could bring along more than you intended, or a task may depend on a second permission that isn’t obvious. We can’t promise that every combination you want is possible in your version of Altru. If a specific action won’t separate cleanly, test it in a sandbox or ask Blackbaud support how that feature’s permissions are structured before you grant it in production.
Upgrades and renewals are sales, not edits
Processing an upgrade at the desk usually runs through the sales side, not a record edit. Make sure the role covers membership sales on the point-of-sale side, and confirm the upgrade lands with the right dates and pricing. Check a couple of test upgrades in your membership reports afterward.
Constituent access is the real exposure
To edit a member, the cashier needs to open the constituent record. Think about what else lives there: giving history, notes, relationships. If your role design can limit which tabs or sections are visible, use that. If it can’t, decide as an organization whether that level of visibility is acceptable for desk staff, and put it in your staff policy.
Keep a paper trail
Ask cashiers to add a short note when they change membership details. If something looks wrong later, the note and the record’s change history tell you who did what and why.
Maintaining it over time
- Name it clearly. “Advanced Ticket Seller” or “Desk Membership Edits” beats “Cashier 2.”
- Document what’s in it. A one-page list of what the role can and can’t do saves a lot of guessing during staff turnover.
- Review after Altru updates. New features sometimes arrive without permissions in custom roles. If cashiers suddenly can’t do something they could last month, check the role first.
- Audit assignments quarterly. Seasonal staff leave; their roles should leave with them.
Quick answers
Do I need Blackbaud to create a custom role?
Usually not. An Altru administrator with security permissions can create and assign system roles. If you don’t see the option, your own account may not have that access.
Can one person have both a ticket role and a membership role?
Yes. Roles combine, which is why stacking a small add-on role is often simpler than one big custom role.
What if cashiers can see more than I want after testing?
Remove the broad feature and grant narrower ones. If the action you need can’t be isolated, confirm with Blackbaud support, and route that task to a supervisor until it can.
