Keep Donor and Participant Data Apart: The Nonprofit Sharing Model

A nonprofit is usually two organizations sharing one database. Development raises money and wants to know everything about a donor. Programs serve people and holds information those people disclosed in confidence. When the same person is both a donor and a participant, or when a major gift prospect turns out to be a client family, the sharing model stops being a technical detail and becomes an ethical obligation. This is the design work nonprofits get least often and need most.

The problem nobody scopes

Here are the situations that force the issue. Every one is real, and every one has happened to organizations that did not plan for it.

• A participant in your housing program makes a 25 dollar donation. Their case notes are now attached to a record a gift officer can open.
• A board member's family receives services from one of your programs. The board member can see the whole org.
• A development officer runs a report on Person Accounts to find lapsed donors and gets columns of program enrollment data back.
• Your wealth screening vendor returns a capacity rating on someone who is a client. A case manager now sees an estimate of that family's net worth.
• A staff member who works Tuesdays in the food pantry and Thursdays on the annual appeal has one login.

The failure is rarely malice. It is a report, a list view, or a related list that shows something to somebody who should not have it. And the cost is not a technical bug: it is a participant who stops disclosing information they need help with, because they worked out that the fundraising team can read it.

Why the role hierarchy fails here

The instinct is to build a role hierarchy that mirrors the organization chart. In a nonprofit that actively creates the problem.

The role hierarchy grants access upward. Anyone above you in the tree sees your records. In a nonprofit chart, development and programs both report up to an executive director, and often to the same deputy. So the moment you use the hierarchy for access, every senior manager sees both sides, and the two branches converge at exactly the level where the most people sit on boards and committees.

Worse, the hierarchy cannot express what you actually need, which is per record and per assignment:

• "The case manager assigned to this family, plus their supervisor, plus nobody else."
• "Gift officers can see donors in their portfolio."
• "Program staff at the east site, not the west site."

None of that is a tree. It is a set of groups and assignments.

So use the role hierarchy for what it is good at, which is reporting rollups and forecast visibility, and keep it flat and simple. Then drive record access with groups and rules.

The design that works

Five layers, applied in order. Each one assumes the previous one is in place.

1. Organization-wide defaults closed on sensitive objects.
2. Public groups representing real teams and functions.
3. Sharing rules opening the minimum each group needs.
4. Restriction rules closing the reporting and list view back door.
5. Field level security hiding the specific columns that must not travel.

Plus encryption where the data class requires it.

Step 1: Set organization-wide defaults

Start closed and open deliberately. This is the opposite of how most nonprofit orgs are configured, and it is the only order that works.

Also turn off "Grant Access Using Hierarchies" on custom objects that hold case detail, where the object supports it. That is what stops the executive director branch from quietly seeing everything.

Step 2: Model teams as public groups

Write down the functional groups that actually exist, not the org chart. A typical nonprofit needs something like:

• Development, split into gift officers and development operations if portfolios matter
• Program staff, usually one group per program or per site
• Case managers, sometimes split by sensitivity tier
• Program leadership
• Finance
• Executive
• System administrators
• Volunteers and interns, which is a group people forget and which needs the tightest access of all

Then pair each group with a permission set that grants object and field permissions. Groups control which records; permission sets control which objects and fields. Keep that separation clean and the model stays understandable when someone new inherits it.

Use permission set groups to bundle by job function, so onboarding is one assignment rather than seven.

Step 3: Open only what each team needs

Now grant the minimum. Some patterns that hold up in practice:

• Criteria-based sharing on record type. If donors and participants use different Person Account record types, share donor records to Development and participant records to Programs. Simple and effective, and it handles the common case where the two populations barely overlap.
• Ownership plus groups for case data. The assigned case manager owns the record. A sharing rule extends it to their team and supervisor. Nobody else.
• Manual or Apex sharing for portfolios. Gift officer portfolios change constantly. Drive them from an assignment field with automation rather than by editing rules.
• Read only where write is not needed. Finance usually needs to read gift data, not edit it.
• Account teams for genuinely shared constituents, where a small number of people legitimately need access to one record.

Every rule should have a written reason. When someone asks in two years why Programs can read a field, the answer must exist in a document, not in someone's memory.

Step 4: Close the reporting back door

This is the step that gets skipped, and it is the one that catches the actual leak.

Sharing rules control which records a user can open. They do not stop a user with broad object access from building a report or list view that surfaces records they were never meant to browse. Restriction rules filter what a user can see through reports, list views, and search, even for records they would otherwise have access to.

Practical uses in a nonprofit:

• Restrict program staff to case records for their own site, so a report cannot pull the whole caseload.
• Restrict development from case management objects entirely, so no report returns a row.
• Restrict volunteers to the specific records their task requires.
• Restrict a shared object to records where the user is on the assignment.

Test this the way a curious employee would. Log in as each persona, open the report builder, and try to get the data out. If you can, the model is not finished. Do this before go-live, and again after any change to permission sets.

Step 5: Field level security for the sensitive columns

Record-level access is coarse. Sometimes a person legitimately needs the record and must not see three fields on it.

Fields to hide from program staff:

• Wealth capacity and philanthropic ratings
• Lifetime giving totals and largest gift
• Major gift stage and solicitation strategy notes

Fields to hide from development staff:

• Diagnosis, disability, and health information
• Immigration status
• Criminal history
• Domestic violence and safety flags
• Benefit eligibility detail

Two cautions. First, formula fields can leak a hidden field's value into a visible one, so audit your formulas. Second, a hidden field can still be exposed by a poorly written Apex class or an integration user with a broad profile. Run field level security checks in your code, and give integration users their own tightly scoped permission sets rather than an administrator profile.

When you need encryption

Field level security controls who sees a field in the application. It does not encrypt the data at rest in a way that protects it from a privileged user or an export.

Shield Platform Encryption becomes worth the cost and the constraints when you hold:

• Health information subject to specific regulation
• Government identifiers such as social security or national insurance numbers
• Information whose disclosure creates physical risk, such as the address of a domestic violence survivor

Understand the trade-offs before you commit. Encrypted fields have restrictions on filtering, sorting, and use in some formulas and search, and that can break existing reports. Encrypt the narrow set of fields that genuinely need it rather than everything, and test your reports afterwards.

Often the better first move is not to store the data at all. If you do not need a social security number, do not collect it. The cheapest way to protect a field is to not have it.

The person who is both

Sooner or later someone is a donor and a participant, and the model has to handle it without special pleading.

Options, in the order we usually recommend them:

1. One record, field and object level separation. The constituent is one Person Account. Development sees the giving objects, Programs sees the program objects, and neither sees the other's fields. This is the correct answer conceptually, because the person is one person, and it requires the sharing model above to be right.
2. One record, restricted to a small group. For a genuinely sensitive overlap, such as a board member's family receiving services, restrict the program side to a named group of two or three people. Document why.
3. Separate records, deliberately not linked. Sometimes the safest thing is that the systems do not know these are the same person. This costs you a unified view, which is a real loss, and for a domestic violence shelter it can be the right call. Make it a conscious, documented decision rather than an accident.

Write your answer into a policy document, not just into configuration. Staff need to know the rule, because they will be the ones who notice the overlap first.

How to test and document it

A sharing model you cannot demonstrate is a sharing model you do not have.

1. Build a persona test matrix. Rows are personas: gift officer, case manager, program director, finance, volunteer, executive director, integration user. Columns are the sensitive objects and fields. Each cell states the expected access.
2. Test by logging in as each persona, not by reading the configuration. Configuration review misses the interactions, and the interactions are where the leaks are.
3. Try to break it. Report builder, list views, global search, exports, related lists, and files. Think like a curious employee, because you have one.
4. Test after every release. A new permission set or a new report type can reopen something you closed.
5. Write the decisions down. One document listing each object, its default, each rule, and the reason. This is what you hand an auditor, and what saves your successor from guessing.

That document is also the deliverable that proves the work happened. Sharing design is invisible when it is right, which is exactly why it needs to be written down.

Frequently asked questions