Beneficiaries and the wall · who can see who is being served
Someone served by a social program is not a fundraising audience. This page explains the beneficiary wall: why that data is kept apart from donor data, who can see a case, how emergency access works and why every access leaves a trace. It is the strictest rule in the vertical and it does not open for anyone's job title.
Why this data is kept apart
The fact that a person is served by a social program is, in itself, sensitive information. It reveals vulnerability, a health condition, a family situation or a legal one. An organization that merges that list with its donor list runs two risks at once: the fundraising team seeing who is being served, and a report or an export carrying the list outside without anyone having decided to.
That is why the link between a person and the beneficiary role does not sit alongside the constituent's other roles. It lives on the other side, and access to it is granted case by case, not by user profile.
What a case's wall is
Every beneficiary has a list of authorized people of their own, shown on screen as Who is on the wall. Whoever creates the case is already on that list, along with whichever program staff are named, otherwise the very person who entered the record could not reopen what they just wrote. After that, joining or leaving the wall is an explicit act, and anyone managing a case's wall has to be able to see that case first.
How the tab behaves
- Open the Nonprofit menu and go to the Beneficiaries tab.
- The list arrives already filtered: only the cases you are authorized to see appear.
- If you are on no case's wall, the list comes back empty with a message saying no case is visible to you.
- Click a case to see the Program, Opened on, who is on the wall and the access trail.
An empty list is not an error or a generic permission problem. It is the correct behavior: a system that said there are 14 cases you cannot see would already have told you something it should not have. Being an administrator of the environment does not open the wall.
Emergency access
There is a path for the urgent situation where someone has to see a case they are not part of. It is an administrative act, it requires a written reason, it is good for a limited time and it expires on its own. On the access trail it is highlighted as break-glass.
The highlight is intentional. Stepping past the wall is only justifiable if somebody can see afterwards that it happened, who did it and why. That is what turns a necessary exception into something auditable instead of a quiet shortcut.
The access trail
Every read of a beneficiary is recorded, and the record is cumulative: entries are appended, never corrected over. The trail answers who opened the case, when, and whether they came in through the wall or through emergency access. It is visible inside the organization to whoever manages the case.
Where the wall also holds
- Beneficiary data never feeds fundraising: it does not enter donor segmentation or campaign lists.
- It is not used to build requests to the AI assistant.
- Every piece of information stored in the vertical carries a classification, and the most protected class is precisely the beneficiary one, which governs how that data can be displayed, exported and retained.
- Isolation between organizations still applies on top of everything: another organization never sees a case of yours.
Common questions
- I am an administrator and I see no cases at all. That is expected. Ask to be added to the case's wall, or use emergency access with a reason, which goes on the record.
- Can I add beneficiary as a constituent role to make things easier? No. That role is refused on purpose, because the role list is open to fundraising.
- Does removing someone from the wall cut their access immediately? Yes, and the history of their earlier accesses remains.
- Can the trail be cleared? No. It is cumulative: that is what makes it useful in an audit.