Salesforce Nonprofit Cloud Integration: A Technical Guide to the Gratefully AI Layer

If you run Salesforce at a nonprofit in 2026, you are on one of two generations of the product, and the difference matters more than it ever has.

Agentforce Nonprofit is the current generation. Salesforce announced the rename from Nonprofit Cloud on December 2, 2025, attaching prebuilt AI agents for prospect research, participant management, volunteer coverage, and donor support. The Power of Us program changed at the same time: since December 2025, new applicants receive 10 free Agentforce Nonprofit CRM licenses instead of the 10 free NPSP licenses the sector relied on for over a decade.

NPSP is the previous generation, and Salesforce has stopped building new capability on it. The clearest dated public signal came in December 2025, when the Power of Us Program removed the ten free NPSP licences it had offered new applicants for years and began issuing ten Agentforce Nonprofit licences instead. Organisations already running NPSP keep their licences and their support, and Salesforce has published no end-of-support date, so nothing is breaking. New investment is simply going somewhere else. Salesforce announced the end of innovation for NPSP in 2024. It remains supported, with no announced end-of-life date, but it has not received a new feature in roughly three years, and none of the new AI agents run on it. Moving off it is not an upgrade: Salesforce implementation partners describe the NPSP to Agentforce Nonprofit transition as a full re-implementation with a different data model, typically taking months.

That leaves thousands of nonprofits in the same spot: a stable, paid-for NPSP org that works, a migration project nobody has budgeted, and AI capabilities gated behind the platform they have not moved to.

This is exactly the gap an integration layer fills. Gratefully connects to both generations, NPSP included, through the same standard Salesforce APIs. You do not need to migrate, buy Data Cloud, or license agents to get cited, plain-English answers from the donor data you already have. Weighing the layer against Salesforce's own AI? That comparison lives on its own page: Gratefully vs Salesforce Nonprofit.

Three names get used interchangeably in this conversation and they are not the same thing.

Agentforce Nonprofit is the current name for Salesforce's purpose-built nonprofit CRM. Salesforce's own product page now leads with the line "Agentforce Nonprofit (formerly Nonprofit Cloud)". Anything you read about Nonprofit Cloud dated before 2026 is describing this product.

Nonprofit Cloud is the previous name for that same product, launched in 2023. It is still in wide use, including on parts of Salesforce's own pricing page, which is why both names appear in this guide.

NPSP, the Nonprofit Success Pack, is the older managed package that installs on top of standard Sales Cloud. It is not an earlier version of Nonprofit Cloud. It is a different data model. NPSP records a donation as an Opportunity. Agentforce Nonprofit splits the same activity into Gift Transactions for one-off gifts and Gift Commitments for pledges and recurring giving.

That last difference is the one that decides everything else on this page. Adding AI to Salesforce is not one question. It is a different question depending on which of the two data models your gifts live in.

Gratefully connects to Salesforce Nonprofit Cloud (NPC), Agentforce Nonprofit, and the Nonprofit Success Pack (NPSP) via standard REST and Bulk APIs. Salesforce remains your system of record for constituents, gifts, recurring schedules, pledges, soft credits, and campaign hierarchies. Nothing about your org changes: no schema changes, no custom objects, no managed package.

What Gratefully adds is a knowledge graph that combines your structured Salesforce records with the unstructured material Salesforce reporting cannot see: gift officer notes, email threads, meeting recaps, board memos, and attached documents. That combined graph is what lets your team ask questions in plain English and get answers cited back to the specific record, note, or email they came from. More on how the graph works: nonprofit knowledge graphs.

The first sync is a bulk backfill through Salesforce Bulk API 2.0. For a typical mid-sized nonprofit, 50,000 to 500,000 constituents and one to five million activity records, the backfill completes in under an hour, with adaptive throttling so it does not crowd out your org's own API limits.

From there, the connector subscribes to Change Data Capture on the eight primary objects, so edits, new gifts, and new activities reach the knowledge graph in near real time. If CDC is not enabled in your org, the connector falls back to incremental polling on SystemModstamp, every five minutes by default. Both paths are idempotent and resumable: an interrupted sync picks up where it left off instead of starting over.

Before anything enters the searchable graph, records pass through PII detection, the same redaction pipeline described in our donor data redaction guide.

Gratefully connects through the standard OAuth 2.0 web server flow against a dedicated Gratefully connected app. Your Salesforce admin installs the connected app, approves the requested scopes, and assigns a least-privilege integration user. The core scopes:

That is the full list. No write scopes, no Analytics scopes, and no hybrid-app session scopes are requested.

Refresh tokens are stored encrypted at rest. Your admin can revoke them at any time from Salesforce Setup, and ingestion halts within one polling cycle.

The same donor shows up as a Salesforce Contact, a separate Account, a spouse on an Affiliation, an email signature, and a name in a meeting note. Gratefully's resolver ties those mentions together using deterministic keys first (Salesforce IDs, email, household roll-up) and probabilistic matching second (name normalization, address fuzzy matching, affiliation graph traversal). Every resolved mention carries a confidence score and a pointer back to the originating Salesforce record, so an answer can always show its work.

Every nonprofit asking this question is in one of three positions, and the honest answer is different in each. Prices below were read on Salesforce's nonprofit pricing page on 3 September 2026 and are per user per month, billed annually.

This is the straightforward path. Salesforce's own agents are built for the data model you are already running.

At announcement, two agents were generally available: Prospect Research, which assembles background on a prospective donor, and Participant Management, which handles programme participant intake and updates. A Volunteer Capacity and Coverage agent and a Donor Support agent followed in beta.

Agentforce 1 for Sales and Agentforce 1 for Service are both listed at $135, against $60 for Nonprofit Cloud Enterprise and $100 for Unlimited. Data Cloud is included at the Agentforce tiers and sold separately below them. Every eligible nonprofit gets ten free licences through the Power of Us Program, and Agentforce capability sits above that free tier.

If this is you, use it. A layer like ours is additive here, not a substitute.

This is where most Salesforce nonprofits actually sit, and where the advice gets least honest, because the people best placed to answer are usually the people who would run the migration.

Here is what is documented. Salesforce's nonprofit agents are built on the Nonprofit Cloud data model. That model is not NPSP's. Moving between them means remapping how every gift in your history is recorded, from Opportunities to Gift Transactions and Gift Commitments, then reviewing every customisation, report and integration built on the old shape. Implementation partners consistently describe it as a reimplementation rather than an upgrade, and they are right that it is not a switch you flip.

That may still be the correct decision. It is a decision about your CRM, though, on a multi-month timeline and a real budget. It is worth separating from the question of whether your team can get useful answers out of your donor data this quarter.

The third option is to leave the data model alone and read it.

This is what Gratefully does. We connect read-only to whichever generation you are on, NPSP or Agentforce Nonprofit, and build the intelligence layer on top of your records as they are. No managed package, no schema changes, no migration as a prerequisite. The rest of this page is the technical detail of how that connection works.

The honest boundary: this is not a replacement for a CRM decision you need to make anyway. If NPSP is genuinely holding your organisation back, migrate. What a read-only layer does is stop the migration timeline from being the thing that decides when your fundraisers get answers out of their own data.

No. This is the question the 2026 rename created, so it deserves a direct answer.

Salesforce's path to AI on nonprofit data runs through its own stack: Agentforce Nonprofit as the platform, Einstein and agent licensing on top, and Data Cloud where unification across sources is needed. That stack is real, and if you are already migrating to Agentforce Nonprofit, the built-in agents are worth evaluating; the side-by-side comparison covers capabilities and cost honestly, and our longer write-up on why Nonprofit Cloud still needs an intelligence layer explains where the two categories diverge.

But none of it is a prerequisite for an intelligence layer. Gratefully needs three things: API access via the connected app, a least-privilege integration user, and read scope on the objects you approve. Those exist on every Salesforce nonprofit org, including NPSP orgs that will never see an Agentforce agent. The knowledge graph, PII redaction, entity resolution, and cited answers all run on Gratefully's side of the API boundary.

The practical implication: an NPSP org can add modern donor AI this quarter without touching its migration timeline, and an org mid-migration can keep its intelligence layer constant while the CRM underneath it changes. The integration is the same either way.