A volunteer coordinator pulls up a longtime member to update their phone number and sees “Major Giving Prospect” listed among their constituencies. Nothing is technically wrong with that. But it’s the kind of label that can travel, gets mentioned at the admissions desk, or lands in a screenshot, and it can make a donor feel watched if it ever reaches them.
So the question is a fair one: can you show that constituency to development staff and keep it from everyone else? The short answer is that Altru’s security is built around features and tasks, not individual constituency values, so there isn’t an obvious per-constituency “hide from these users” setting. What you can do is narrow where that label appears, who can reach the records and tools that expose it, and how much the label actually reveals.
How Altru security actually works
Altru controls access through system roles. A role grants or denies permission to features: pages, tabs, forms, queries, reports, and tasks. A user’s effective access is the combination of all the roles assigned to them.
That model is good at “this person can’t open prospect records” or “this person can’t run that query.” It’s not designed for “this person can open the constituent record and see the constituency list, minus one entry.” Constituencies show up as a list on the constituent record, and as far as we know there is no role setting that filters a single value out of that list for some users.
We’d rather be plain about that than guess. If you need certainty for your version, set up a test user in a sandbox or ask Blackbaud support directly: “Can a system role hide one specific constituency from a user who can otherwise view constituent records?” Get the answer in writing so the next administrator doesn’t have to ask again.
Decide what you’re really protecting
Before changing roles, be specific about the risk. In most organizations, the label itself isn’t the sensitive part. The sensitive parts are what sits behind it:
- Wealth screening results, capacity ratings, and giving estimates
- Prospect plans, steps, and the notes development officers write after meetings
- Lists of who is in the major gifts pipeline, especially when exported
If a front-line employee seeing “Major Giving Prospect” on one record is a minor issue, but that same person being able to export every prospect with a capacity rating is a serious one, put your effort into the second problem. That’s also where Altru’s security model gives you the most control.
Levers you do have
1. Tighten roles for non-development staff
Review the roles assigned to admissions, membership, volunteer, and retail staff. Remove access to prospect-related pages, tabs, and tasks they don’t need for their jobs. Many organizations find that front-line roles were cloned from an admin role years ago and still carry far more than anyone intended. Build front-line roles up from the minimum rather than trimming down from everything.
2. Lock down queries
Queries are the easiest way for prospect data to leave the building. Check which shared queries return constituency, and set permissions on those queries so only development roles can run or edit them. Also consider whether front-line roles need ad-hoc query access at all. Someone who can build a query against constituents can usually filter on constituency, which surfaces the full prospect list in seconds.
3. Review reports, exports, and smart fields
Look at any report, export definition, or smart field that touches constituency or prospect data, and check which roles can reach it. A summary or list built for the development office can end up on a dashboard that the whole staff sees.
4. Make the label say less
If the constituency name itself is the concern, consider whether you need it on the record at all for your process. Some teams keep pipeline status in places that only development roles can reach, and use the constituency sparingly or not at all. Before changing anything, check which Altru features, reports, or prospect workflows depend on that constituency, because some may be tied to it. If you aren’t sure, test in a sandbox first.
5. Put policy where software can’t reach
Some visibility will remain. Cover it with a short written data-use guideline: staff may see donor information as part of their job, it stays in Altru, it isn’t discussed with visitors, and screenshots of constituent records don’t go into chat or email. Add it to onboarding for seasonal staff, who are the ones most likely to have broad record access and the least context.
Test as the user, not as the admin
Role changes are easy to get wrong in both directions. Create a test login for each front-line role and click through what that person actually does: look up a member, process a sale, run their usual queries, open their dashboards. Confirm two things: the prospect information you meant to restrict is gone, and nothing they need for their daily work broke. Then revisit roles once a year, or whenever a new department starts using Altru.
Quick answers
Can I hide one constituency from specific users in Altru?
Not that we’re aware of as a direct setting. Security is applied to features and tasks rather than individual constituency values. Confirm for your version with Blackbaud support or a sandbox test.
Should I remove constituent record access from front-line staff?
Usually not. Admissions and membership staff need constituent records to do their jobs. Limit the tools around the records, such as queries, exports, and prospect tabs, instead.
What’s the biggest real exposure?
Usually queries and exports, not the label on a single record. A list of every major gift prospect is far more sensitive than one constituency tag.
