NPSP Migration Decisions · AD-4

Who sees and changes which records in the target — and with which licenses?

A migration is the one moment an organization gets to rethink who can see donor and gift records. The target’s sharing model, roles, permission sets[1] and licenses are configured fresh — so the question is not “what did NPSP do?” but “what should the new org do?” Donor and gift records are personal data; program participation, where present, is sensitive and separate from fundraising[2].

Talk to an Architect All 16 decisions

Who decides

Executive sponsor with the Salesforce administrator

Decide after

No prerequisite — decide in parallel

Estimated effort

M  personas, permission sets, license check

What answers it

The current sharing model in NPSP, the personas who work donors, gifts and programs, and the permission-set licenses the fundraising objects require.

Your options, and what each one does

The Options
The optionWhat it means for the migration
Private by default, opened per personaOrg-wide defaults private for Person Accounts and the gift objects; access granted by role and by permission set per persona (fundraising, finance, administrator). Each persona gets the permission-set licenses the fundraising objects require.
Public read, restricted editSimpler sharing; everyone reads donors and gifts. Defensible when the organization already relies on a public model and is small enough to reason about it.

What Horus Eye recommends — and when

Recommendation, Not Verdict

Private by default, opened per persona — access to personal data granted for a purpose. Confirm with Salesforce which permission-set licenses each persona needs for the fundraising objects; that detail is not readable from the org’s metadata and has a licensing cost attached.

A recommendation is a starting point, not a verdict. The same question lands differently org by org — one fact about your automation, volumes or vendors can flip the right answer. That is why the reasons are stated, and what would change them.

How this decision plays out

In Practice

A migration is the one moment you get to rethink access without a change-management project, because everything is being configured fresh anyway. The question is not “what did NPSP grant?” — years of accumulated permissions are part of what you are leaving — but “who needs to see and change what, now?” Donor and gift records are personal data; the private-by-default posture, opened per persona (fundraising, finance, administration), grants access for a purpose rather than by inheritance. Where program management is in scope, say the quiet part aloud: program participation is sensitive in its own right, and its access model should be separate from fundraising’s, not inherited from it.

The pragmatic counterweight: a small team already living happily on a public sharing model should not buy complexity it will not maintain — a sharing model nobody understands is its own security risk. Two details deserve early attention because they carry cost and lead time. Permission-set licenses: which ones each persona needs for the fundraising objects is a licensing question to confirm with Salesforce, not something readable from metadata. And testing: every persona gets a test user that proves its access — both what it can reach and what it cannot — as part of go-live criteria, not after.

Questions to settle before you record an answer

Before You Decide
The decision owners map: sponsor, fundraising, finance, operations, admin, architect and program lead
Drawn for this decision — the trade the options actually make.

How Horus Eye helps

With Horus Eye

When Horus Eye assesses an NPSP org, this question is raised with the evidence the scan saw — the record types, fields and settings behind it — its recommendation marked, and the reasons stated. Accept records the recommendation; Change opens the options. Recording an answer writes nothing to Salesforce: it is captured in the decision register, with who decided and when, and the migration plan, mappings and documents are kept consistent with what your organization actually decided. Horus Eye recommends; your organization decides.

Sources & further reading

References

Protected AI — the Trust Layer

Every AI read in Horus Eye is metadata-first: built from an allowlist, sanitized by pattern, made through one audited gateway and checked by an output firewall on the way back — and AI is off by default, per org. Every request carries an audit id and an AI Data Scope manifest you can open.

See the Trust Layer

Facing this decision in your own org?

Horus Eye

A read-only assessment puts the evidence behind it on the table — what your org holds, what it means for this choice, and the decisions that depend on it.

Try Horus Eye Free Request an Assessment All Horus Eye pages

Free start · 250 credits for 60 days · no card required · scans are free