The Agentforce Nonprofit Data Model Explained

Most confusion about Agentforce Nonprofit, the product Salesforce used to call Nonprofit Cloud, comes from the data model rather than the features. It replaces the Household Account pattern that nonprofit consultants have used for a decade, and it introduces roughly a hundred objects that ship as part of the platform instead of a package. This is a working reference: the objects that matter, their API names, how they connect, and the choices you have to make before you build.

The one design decision behind everything

Salesforce moved industry function out of managed packages and into the core platform. For nonprofits that has three consequences worth understanding before you look at a single object.

• No namespace prefixes. You work with GiftTransaction, not npsp__Gift__c. These are standard objects, documented in the standard object reference, available to Flow, Apex, reports, and the API like any other.
• Objects arrive with platform releases. You do not install or upgrade a package. New fields and objects show up in the seasonal release, which is why API version numbers matter when you read the docs.
• The model is shared across industries. Grantmaking objects such as FundingAward and Budget, and the outcome objects, are also used by Public Sector Solutions. That is why some field labels sound governmental. It also means the model is broader than any one nonprofit needs, and part of your design work is choosing what to ignore.

People, households, and organizations

This is the biggest change from the Nonprofit Success Pack, so it is worth being precise.

A person is a Person Account

An individual is an Account with the Person Account record type, paired one to one with a Contact record behind the scenes. The user sees one record. Donors, program participants, volunteers, board members, and staff at a funder are all Person Accounts.

This matters because in NPSP an individual was a Contact that had to belong to a Household Account. Here the individual stands alone and does not need a household at all.

A household is a business Account plus a Party Relationship Group

A household is an Account that is not a Person Account, with a related PartyRelationshipGroup record that declares what kind of group it is. The PartyRelationshipGroup has a master-detail relationship to Account, and its Type field takes the values Group or Household, defaulting to Group.

It also carries the group-level attributes programs care about, including a Subtype with values such as Nuclear Household, Extension Household, and Three Person Household, plus group size, group income, and a HousingType field in more recent API versions.

The important behavioural difference: households are not created automatically. In NPSP every Contact got a household whether it was meaningful or not. Here you create groups deliberately, which is better modelling and more design work.

Membership is an Account Contact Relation

People join a household through AccountContactRelation, linking the group account to the person account's contact record. Roles on that relation are what you use for salutation logic and mailing decisions.

Two permission notes that catch teams out. Creating party relationship groups needs the Group Membership permission set. Merging groups needs the Merge and Split Groups system permission, which you enable in a clone of that permission set. There is also a Group Definitions business API for creating a group, its members, and its related accounts in one call, which is the right tool for intake forms.

An organization is a business Account

Companies, funders, partner nonprofits, and government bodies are ordinary business accounts. People who work there are Person Accounts related to the organization.

Contact Points: email, phone, address

Contact details live on separate related records rather than fields on the person.

This is more work to build and much better for real nonprofit operations. A participant with a shelter address and a mailing address, a donor with a seasonal address, and a board member with a work and a home email are all natural here. In NPSP they needed the address management package or custom fields.

Consent and opt-out belong on these records. If you run email through Marketing Cloud, Account Engagement, or Mailchimp, decide which system owns consent before you build, because two systems both believing they own it is how organizations end up emailing people who asked them to stop.

Relationships between people and organizations

Note that you write both directions of a person-to-person relationship yourself. NPSP created the reciprocal record automatically, so this is a common gap in migrations. If your relationships need to be navigable both ways, build automation for it during implementation.

Fundraising objects

The fundraising model is the largest area, and the one where getting the concepts right prevents double counted revenue. Core objects first:

The concept that matters most: a commitment is a promise and a transaction is money received. A monthly donor has one GiftCommitment, a GiftCommitmentSchedule, and one GiftTransaction per successful payment. A five year pledge works the same way. If you report on commitments and transactions added together, you will overstate revenue, and the numbers will not survive an audit.

Major gifts and planned giving

Larger shops get more objects, and most organizations should ignore them at first.

• DonorGiftConcept holds the early idea for a gift, including donor intent, before it becomes a commitment. DonorGiftConceptOpportunity joins it to an Opportunity.
• GiftAgreement records the agreement to accept a gift, which matters when gifts come with conditions.
• PlannedGift covers annuities, bequests, and trusts, supported by PlannedGiftAnnuityRate, PlannedGiftPerformance, GiftActuarialEntry, and GiftValueForecast.
• GiftStewardship and GiftStewardshipActivity track stewardship by someone who is not the donor.

Prospect research and wealth data

Wealth screening output has a home instead of a pile of custom fields: PartyPhilanthropicAssessment for formal valuations, PartyPhilanthropicIndicator for soft signals, PartyPhilanthropicMilestone for activity over a period, and PartyPhilanthropicRsrchPrfl as the research pivot point. PartyCategory classifies constituents for a time period, which is how you model segments that change.

This is also what the Prospect Research Agent reads. If you leave wealth data in custom fields, the agent cannot see it.

Program management objects

Program delivery is core platform function now, not a separate package.

Read the chain as: a person enrols in a Program, that enrolment assigns them to one or more Benefit records, schedules say when delivery happens, and each real delivery is a BenefitDisbursement. Disbursements are what you count when a funder asks how many meals, sessions, or bus passes you actually provided.

Program Management also ships Data Processing Engine definitions, which is how enrolment and disbursement totals get calculated at scale rather than with per-record automation.

Outcome management objects

This is the part with no NPSP equivalent, and for many organizations it is the strongest reason to be on the current platform. All of these arrived in API version 59.0.

The layering is deliberate. A definition says what "job placement retention at 90 days" means. An assignment attaches it to a specific outcome. A performance period sets the baseline and the target for a quarter. Results hold the numbers. That separation is exactly what lets two funders measure the same program differently without you duplicating fields, and IndicatorDefinition can point at a Flow to compute results.

More detail in program and outcome management.

Grantmaking objects

These serve organizations that give money away, and they are shared with Public Sector Solutions.

The participant objects are how you grant record access to reviewers and programme officers without inventing sharing machinery. Full walkthrough in grantmaking on Salesforce.

How totals get calculated

If you come from NPSP, this is the habit that needs to change. NPSP gave you Customizable Rollups driven by custom metadata. Agentforce Nonprofit relies on Data Processing Engine definitions plus standard summary objects such as DonorGiftSummary.

Data Processing Engine runs in bulk on a schedule. The trade-off is real: it scales to millions of records without hitting limits, and the numbers are not instant. Decide per figure whether staleness is acceptable.

• Fine to batch. Lifetime giving, largest gift, first and last gift date, donor segments, program totals.
• Needs to be live. Anything a user checks during a phone call, or an agent quotes to a donor. Build these with a formula field, a lightweight flow, or a query in the moment.

Where a genuine real-time cross-object total is required, the same pattern we describe in rolling up fields across a lookup relationship still applies.

Five design choices you have to make

1. Which groups are real? Households are not automatic now. Decide whether you group by household, by family, by shared address, or not at all. Fundraising usually wants households; programs often want a different grouping such as a family unit or a shelter placement.
2. Which record types? You can have record types on Person Accounts. Splitting donors, participants, and volunteers into different record types gives you distinct layouts and cleaner page design, and it also becomes part of your sharing model. Do not overdo it: one person is often all three.
3. What is a designation, and who owns the list? Designations map to how finance reports restricted funds. Get the finance lead to own the list, or it grows to 200 entries and reporting becomes meaningless.
4. Where does consent live? Contact Point records, and one system of record. Write the decision down.
5. How separate are donor and program data? This is the architecture question with the highest cost of getting wrong, and it has to be answered before the objects exist. See the nonprofit sharing model.

Frequently asked questions