NPSP Migration Decisions · MD-1

How will households be represented in Agentforce Nonprofit?

NPSP keeps each household as an Account; Agentforce Nonprofit (aka Nonprofit Cloud) keeps people as Person Accounts[2] grouped into household Party Relationship Groups. Every donor, gift rollup and relationship is mapped through this choice — which is why it comes right after the target-org decision, and before gift classification.[3]

Talk to an Architect All 16 decisions

Who decides

Executive sponsor with the fundraising lead

Decide after

AD-1 (target org strategy)

Estimated effort

L  count first, then align the stakeholders

What answers it

The NPSP account model in use (the Household Account record type on Account), and — with counts-only profiling — how many households have one member or none.

Your options, and what each one does

The Options
The optionWhat it means for the migration
Households become Party Relationship GroupsSalesforce’s documented mapping: each household stays a business account, marked as a household by its Party Relationship Group; its people join through account–contact relationships, and a household gift’s hard credit moves to its primary contact.
Households only where people share oneThe recommendation of Salesforce’s Migration Guide v2.0[1] (§5.4.2): only households with more than one member are kept; a one-member household’s person stays a Person Account without a household — fewer records, but no household-level giving or greeting for them.
Individuals only — no householdsEvery person stands alone; household giving, greetings and addresses move to the people, and household reporting is redesigned.
The three NPSP household-model options: every household becomes a group, only shared households are kept, or individuals only
Three options, one arithmetic question first: how many of your households have one member?

What Horus Eye recommends — and when

Recommendation, Not Verdict

Keeping households only where people actually share one, when the org uses NPSP’s Household Account model — because NPSP creates a household account for every contact, so this option can remove a large share of account records. The trade-off: a one-person household loses household-level giving and greetings. Count your one-member households before you choose.

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

The reason this decision ripples so far: NPSP creates a household account for every contact, including people who live alone. In a typical NPSP org a large share of households have exactly one member, so the middle option — keep households only where people actually share one — can remove a surprising fraction of your account records, which is why it is the Migration Guide’s own recommendation. The price is specific and worth saying to your fundraising lead out loud: a one-person household loses household-level giving history, household greetings and the household address record, because that person now stands alone as a Person Account. If your acknowledgement letters, year-end receipts or major-gift reports are written at the household level for everyone, the model you choose changes what those documents say. Choosing “individuals only” goes further still: household reporting is not migrated but redesigned, which is honest work — just budget for it.

Whichever way you lean, count before you choose. The number of one-member households, the number of households with shared giving, and the reports that aggregate at household level are all measurable in NPSP today — and they turn this from a philosophical debate into an arithmetic one.

Questions to settle before you record an answer

Before You Decide
Horus Eye decision drawer for the household model: what the scan found, why it matters, the three options, and what changed when the answer was recorded
A decision, with its evidence and its consequences — recorded, not just discussed.

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