A Person Account is a single Salesforce record that represents one individual as both an account and a contact at once. It's the data model Nonprofit Cloud uses for constituents — and it's the biggest structural difference from NPSP, which instead groups Contacts underneath Household Accounts. Understanding this one concept explains most of why an NPSP → Nonprofit Cloud migration is a real project rather than an upgrade.
The two models, side by side
In standard Salesforce, an Account is an organization and a Contact is a person who works there. NPSP bent that business-world model to fit nonprofits by inventing the Household Account: each donor is a Contact, and Contacts are grouped into a Household Account that represents the giving unit.
Nonprofit Cloud takes a different route. A Person Account collapses the account and the contact into one record for an individual. There's no separate household wrapper by default — the person is the record.
| NPSP (Household model) | Nonprofit Cloud (Person Accounts) | |
|---|---|---|
| A donor is… | a Contact inside a Household Account | a single Person Account record |
| The giving unit | the Household Account | modeled with relationships/groups, not a wrapper account |
| Built on | custom objects layered on the platform | standard Salesforce objects |
| Used by | nonprofits, via NPSP | Salesforce Industries products (finance, health) and now nonprofits |
Why Salesforce chose Person Accounts for nonprofits
Person Accounts aren't new — they're the same model behind Salesforce's financial services and healthcare products. By putting nonprofits on that shared foundation, Salesforce lets Nonprofit Cloud inherit platform-level investment automatically: Data Cloud, Flow, and the AI roadmap are all built against standard objects and Person Accounts. That's the payoff, and it's why new features never come to NPSP.
What breaks when you move
Because the models are structurally incompatible, several things you take for granted in NPSP have to be rebuilt, not copied:
- Households and giving units. The Household Account disappears as a container; household giving summaries and "who lives together" have to be re-expressed with relationships.
- Soft credits. How you credit a spouse, a matching employer or an influencer for a gift is modeled differently and must be re-mapped.
- Relationships. NPSP's relationship records map onto Nonprofit Cloud's relationship model with different objects and behavior.
- Rollups. Household and contact rollups (total giving, last gift, largest gift) are recalculated in the new architecture.
This is exactly the work covered in NPSP data migration: mapping Households to Person Accounts, and it's the reason the migration timeline spends real weeks on data mapping.
What it means for reporting
The upside of the new model shows up in reporting. Because constituents, programs, cases, outcomes and gifts all live on one standard data model, Nonprofit Cloud can answer cross-mission questions — which programs do our major donors fund, and what outcomes did those programs deliver? — without stitching spreadsheets together. If you want the full product comparison, see NPSP vs Nonprofit Cloud. If you're weighing the move, the readiness check gives an honest verdict in six questions.
Frequently asked questions
What is a Person Account in Salesforce Nonprofit Cloud?
A Person Account is a single Salesforce record that represents one individual as both an account and a contact at once. Nonprofit Cloud uses Person Accounts for constituents, unlike NPSP, which groups Contacts under Household Accounts. It's the same model behind Salesforce's financial services and healthcare products.
How are Person Accounts different from NPSP Households?
NPSP models a donor as a Contact inside a Household Account (the household is the giving unit). Nonprofit Cloud collapses account and contact into one Person Account record, with relationships and groups expressing who gives together. The two models are structurally incompatible.
Why does the Person Account model matter for migration?
Because it's incompatible with NPSP's Household model, data can't move one-to-one. Households, soft credits, relationships and rollups all have to be re-mapped rather than copied — which is why the migration's data-mapping phase takes real time and drives much of the cost.
Yash
Founder & Principal Consultant, Ynexgen
Yash leads Ynexgen, helping small and mid-sized businesses turn technology into a stronger foundation for growth — 7+ years across Salesforce CRM, websites, and AI adoption.
