Nonprofit Hub

Just starting out with Agentforce Nonprofit (AFNP)? Getting stakeholder management right — individuals, households, relationships, affiliations — is one of the hardest parts of a new implementation. There are a lot of objects, a lot of settings, and a lot of choices to make at once. 

The Stakeholder Management Quick Start is a free, open-source Global Public Sector Accelerator built specifically for new AFNP customers. It installs an unmanaged package with best-practice configuration already in place — so admins can focus on their organization's needs instead of figuring out the plumbing. 

Who is this for?

 Admins and implementation teams starting a new Agentforce Nonprofit implementation who need the stakeholder data model set up correctly from day one. 

Why was this built?

The AFNP stakeholder model — households, relationships, affiliations, contact points — requires dozens of interconnected decisions before staff can use it effectively. Without a clear starting point, implementations often end up with duplicate records, broken address syncs, and cleanup debt that builds silently for months. This accelerator provides the starting line. 

How can it help me?

Install the package and get the following out of the box:

• Households — automated household naming, Party Relationship Group creation, and a guided screen flow for adding/removing members and managing per-member address and phone sync
• Relationships & Affiliations — guided flows for individual-to-individual, person-to-org, and org-to-org relationships with automatic reciprocal creation, customizable roles, and support for preserving history
• Contact Info — Contact Point Address, Phone, and Email as the system of record, with per-member household sync that respects individual preferences
• Setup — custom app, Dynamic Lightning Pages, permission sets, quick actions, and field help text ready to go

What does it cost?

Nothing. It's free and open source. 

Check out the accelerator here: https://sfdc.co/smqs

Read more here: https://www.linkedin.com/pulse/getting-stakeholder-management-right-from-vm2lc/

Hi everyone, 

I've posted on the Impact Exchange hoping to get some assistance with this, but I also wanted to ask the community to get more eyes on my problem. I am to the point of overthinking this problem to the point that I can't make a decision to move forward. Essentially I am having trouble figuring out how to accurately report on major donors who give through multiple entities — their household plus one or more personal businesses/LLCs — in NPSP. I'm trying to get an accurate combined giving for the primary contact without breaking lapsed-donor reporting or requiring a lot of manual upkeep. Curious what's worked for others (Account Hierarchy, Contact-level rollups, something else). I am having trouble make soft credit work for my needs. 

Here is the description of my Impact Exchange project for more context:  

neverthirst is a nonprofit running on Salesforce NPSP (Household Account model), with a growing base of major donors who give through multiple entities — their personal household account plus one or more owned businesses (LLCs, foundations, etc.), sometimes four or five per person. We need to reliably report each donor's total giving across every entity they touch, for major-donor stewardship, lapsed-donor tracking, and Top-Donor reporting — without a donor falsely showing as "lapsed" just because they gave through a different business account than last year. 

I've prototyped two approaches and want an outside expert to pressure-test the direction and help us build it out properly: (1) NPSP Account Hierarchy, with businesses as child accounts under a household parent, rolled up via custom fields — functional, but dependent on manually maintaining the hierarchy every time a donor's business gives for the first time, and it breaks down when two people co-own the same business and both need full credit. (2) A Primary Contact + soft/hard credit model using NPSP's native rollup fields — less manual maintenance, but a bigger restructuring effort. 

Looking for someone with hands-on NPSP experience specifically with multi-entity/household+business donor attribution, who can help us pick (or improve) an architecture, build the supporting rollups and reports, and leave us with documentation our (small, non-technical) team can maintain going forward. Comfortable with an iterative, hands-on engagement rather than a one-time consult — this needs someone in the weeds with us.

Hi Community,

We're a nonprofit implementing Agentforce Nonprofit with Program and Benefit Management enabled, and we're looking for advice on our data model for storing ride information from an external ride provider.

Our Use Case

We offer secure rides as a client benefit. Ride data is sourced from external ride provider’s system and pushed into Salesforce via API. A key requirement is that we do not store any PII in Salesforce — client identity is managed through tokenized Person Accounts (e.g., "Client 00123") with an External ID that maps back to the source system.

Our Proposed Data Model

We plan to use the native Agentforce Nonprofit Program and Benefit Management hierarchy:

Program → Benefit (Type: Service) → Program Enrollment (Token-based Person Account) → Benefit Assignment → Benefit Disbursement (each individual ride)

Each ride from an external ride provider would be stored as a Benefit Disbursement record, upserted via API using an External Ride ID field. We'd add custom fields to the BenefitDisbursement object (surfaced via the Benefit Disbursement Field Set) to capture ride-specific data from the external ride provider, including:

- Pickup and Drop-off DateTime (UTC), City, State, and Zip Code

- Distance (miles) and Duration (minutes)

- Ride Cost, Transaction Amount, Transaction DateTime, and Transaction Type

- Ride Type, Fare Type

- Scheduled Ride ID and Flex Ride ID

We are not storing street addresses — only city, state (using State/Country picklists), and zip code to keep the data PII-safe.

Our Questions

1. Is BenefitDisbursement the right object to store individual ride events from an external system, or would you recommend a different approach?
2. Are there any limitations of the BenefitDisbursement object we should be aware of when storing high-volume records from an external integration?
3. Has anyone used the Benefit Disbursement Field Set to surface ride- or service-specific custom fields, and are there any gotchas?
4. Any considerations we should keep in mind for reporting on ride utilization (rides used vs. rides allocated) using this model?

Any advice or experience with similar implementations would be greatly appreciated!

Thank you!