Education Cloud and Nonprofit Cloud both include Salesforce Fundraising on the same objects. Education Cloud adds alumni relations, corporate relations, and the student record. The decision turns on whether advancement shares a Salesforce org with admissions, student success, and commerce, or a separate foundation runs its own. ElevateActual recommends Education Cloud for the first and treats the second as open.
What Does Each Product Include for Advancement?
Salesforce Help describes Fundraising as "an integral part of the Salesforce Nonprofit and Education Clouds." The same product, on the same objects, appears in both. In Education Cloud it sits under Alumni and Advancement, documented on Salesforce Help at Alumni and Advancement and Fundraising in Education. The Fundraising features Help lists include major gift and grant fundraising, mass market fundraising, guided flows for batch and single gift entry, donation rollups by donor, household, campaign, and designation, gift commitments with recurring schedules, soft credits, gift planning, Recency, Frequency, and Monetary Value (RFM) scoring, acknowledgment and receipt templates, and four apps: Fundraising Strategy, Donor Engagement, Philanthropy and Partnerships, and Fundraising Operations. Our advancement practice builds on these objects in either product.
Status. What Education Cloud adds on top of Fundraising is the rest of the institution: Alumni Relations, Corporate Relations, and the student record itself, so that the person who applied, enrolled, graduated, and gave is one Person Account with one history. Agentforce for Fundraising (Donor Support, Donor Engagement, and Philanthropic Research agents) is documented under Education Cloud's Alumni and Advancement section as well. Rationale. Nonprofit Cloud is the fundraising product for nonprofits. It carries the same Fundraising objects and apps, surrounded by nonprofit program records rather than a student record. Platform rule: the gift objects are the same code in both products, so the choice is about the records around the gift, not the gift itself.
How Do You Decide?
The decision is organizational before it is technical. What to decide. Whether advancement shares the Salesforce org with admissions, student success, and the storefront, or a legally separate foundation runs its own org with its own administrators, its own security, and its own board.
When advancement shares the org, Education Cloud is the answer, and not a close one. The alumni record is the student record aged forward. Degrees, affiliations, involvement groups, and program history are already on standard Education Cloud objects. A donor who is also a parent of a current student, an adjunct instructor, and a continuing education learner is one Person Account. Running Nonprofit Cloud in that org would mean a second product license for the same Fundraising objects and a second set of apps over the same people.
When a separate foundation runs its own org, either product works, and Nonprofit Cloud is the common choice because the foundation is a nonprofit: it files as one, it reports as one, and its staff think in campaigns, designations, and gift commitments rather than terms and cohorts. The foundation still needs alumni and degree data from the university, and that becomes an integration between two orgs rather than a shared record. Education Cloud in a foundation org is a reasonable choice when the foundation expects to merge with the university's org later, or when it wants alumni relations features natively rather than by integration. Platform rule: two orgs means two sets of Person Accounts for the same people, kept in step by integration, forever.
| Question | Nonprofit Cloud | Education Cloud |
|---|---|---|
| Which Fundraising objects does it use? | Salesforce Fundraising: GiftCommitment, GiftTransaction, GiftDesignation, GiftSoftCredit, GiftEntry | The same objects, documented under Alumni and Advancement |
| Who else lives in the org? | Nonprofit programs, constituents, and grants | Applicants, students, learners, instructors, alumni, donors, on one Person Account per person |
| Where does the alumni record come from? | Imported or integrated from the university | The student record, aged forward, with Alumni Relations features native |
| Corporate and foundation relations | Grant seeking on Fundraising objects | Corporate Relations plus grant seeking on the same objects |
| Household naming | Automatic household naming with Salesforce's household creation and naming add-on | Same feature, same add-on, per Salesforce Help |
| RFM scoring and rollups | Data Processing Engine jobs on gift data | Same jobs, same configuration |
| Accounting Subledger | Included with Fundraising per Salesforce Help | Included with Fundraising per Salesforce Help |
| Online giving storefront | Salesforce Commerce on the same org, gifts written to Fundraising objects | Same storefront pattern, and the same cart can sell courses, memberships, and tickets |
| Agentforce for donors and gift officers | The same Fundraising agents, with the Agentforce add-on | Donor Support, Donor Engagement, and Philanthropic Research, documented in Education Cloud Help, with the add-on |
| Best fit | A separate foundation with its own org and no student data | Advancement sharing an org with admissions, students, or a storefront |
What Do Person Accounts Versus Households Mean for Gift Crediting?
This is the question advancement teams coming from Raiser's Edge ask first, because their old system credits a constituent record and rolls up to a household or spouse through relationships. Status. Education Cloud Fundraising requires Person Accounts. Salesforce Help lists enabling Person Accounts as a Fundraising prerequisite, and it notes the opposite constraint for the older Nonprofit Success Pack, where Person Accounts are not supported. A person in Education Cloud is one Person Account, which is both an Account and a Contact behind the scenes. A household is a group: a separate household Account with Group Membership records linking the people in it. Salesforce Help's household naming feature generates and maintains the household name and greeting from a template, for example "Sam and Sally Smith Household," and recalculates it when members change. Help lists this feature with an automatic household creation and naming add-on for both Agentforce Nonprofit and Agentforce Education.
Rationale. The gift itself is credited to the donor. A GiftTransaction and its GiftCommitment carry the donor as the Person Account that gave. The household sees the gift through rollups, which Help describes as summarizing donor, household, campaign, and designation data. Influence is recorded separately through soft credits: a GiftSoftCredit names another person or organization, a role such as Matched Donor or Spouse, and an amount or share, and a default soft credit on a commitment applies to every gift under it. Help notes that soft credits may exceed the gift itself. Method. Decide three things before migration: which record is the hard-credit donor when a couple gives jointly, whether spouse crediting is a soft credit or a household rollup, and what the household naming template is. Platform rule: hard credit lives on the person, aggregate credit lives on the household rollup, and recognition credit lives on soft credits; a migration that collapses those three into one field will not reconcile. Our guide to moving from Raiser's Edge to Salesforce covers the mapping.
Where Does Accounting Subledger Fit?
Status. Salesforce Help describes Accounting Subledger as included with Fundraising. It generates accounting data from gift transactions, through accounting sets that map gift designations, payment methods, and statuses to general ledger accounts, and through jobs that produce transaction journals an accounting system can import. Help's Education Cloud article lists donations, grants, scholarships, tuition, library fees, food programs, and application fees as use cases. Rationale. An advancement office does not close the books; the foundation's finance team does, in its own general ledger. The subledger's job is to hand that team a journal that already carries the fund and account mapping, so that reconciliation is a comparison rather than a rebuild. Method. The accounting set is designed with the controller, not the gift officers, and it is designed before go-live, because every gift posted without it has to be journaled by hand. Platform rule: Accounting Subledger prepares entries; the general ledger remains the system of record for the money.
How Does Online Giving Fit?
Online giving does not come from Fundraising by itself. Salesforce.org Elevate, the former Giving Pages and Payment Services product, was retired, with new sales ended in April 2023 and deactivation on or after October 1, 2024. ElevateActual is not affiliated with it. What an institution builds instead is a giving storefront on Salesforce Commerce, which we call Commerce on Core: B2B or D2C Commerce on the Salesforce Platform with an LWR Experience Cloud storefront, where designations are products, the gift is an order, and post-order automation writes the gift to the Fundraising objects. The same cart sells memberships, event tickets, and courses, which is the practical reason an institution with a continuing education storefront wants advancement in the same org. The article on online giving on Salesforce Commerce describes the patterns from a giving storefront we built, including any-amount gifts, pledge installments, and giving-day load. Platform rule: the storefront takes the payment; the Fundraising objects record the gift; neither replaces the other.
What to Decide
What to decide. First, the organizational question: one org or two. If the foundation and the university share an org, choose Education Cloud and stop debating. If they do not, decide whether they ever will, because that answer tilts a foundation org toward Education Cloud. Second, the gift crediting rules: hard credit, household rollup, soft credit, and the household naming template, written down before any data moves. Third, the accounting set, designed with the controller. Fourth, the online giving channel, which is a Salesforce Commerce storefront in either product. Fifth, the licensing line, confirmed in writing by the Salesforce account executive: the household naming add-on, the Agentforce add-on if donor agents are in scope, and the Commerce licenses for a storefront. Salesforce's Education Cloud pricing page is the published reference; we do not quote figures. The glossary defines the objects named here, and the guide to Salesforce for higher education places advancement beside admissions, student success, and commerce.
Questions We Hear
Are the fundraising objects really the same in both products?
Yes. Salesforce Help describes Fundraising as an integral part of both the Nonprofit and Education Clouds, with the same gift commitment, gift transaction, designation, soft credit, and gift entry objects, the same four apps, the same rollups and RFM scoring, and the same Accounting Subledger. The difference is what surrounds the gift: Education Cloud carries the student and alumni record natively, and Nonprofit Cloud carries nonprofit program and case management. Pick the product by the people in the org, not by the gift features.
Our foundation is a separate legal entity. Does that force Nonprofit Cloud?
No. A separate foundation with its own org can run either product. Nonprofit Cloud is the common choice because the foundation is a nonprofit and its staff think in nonprofit terms. Education Cloud in the foundation org makes sense when the foundation expects to merge orgs with the university later, or wants alumni relations features natively rather than through integration. Either way, plan for the alumni and degree data to flow from the university's org, kept in step by integration, as a permanent cost.
How does a joint gift from a couple get credited on Person Accounts?
One Person Account is the hard-credit donor on the gift transaction and commitment. The household, a separate group Account with the two people as members, sees the gift through household rollups. The spouse receives recognition through a soft credit with a role and an amount or share, and a default soft credit on the commitment applies to every installment. Decide the rule before migration, because Raiser's Edge data often carries the couple on one constituent record with a spouse relationship, and that has to be split deliberately.
Does Accounting Subledger replace our general ledger?
No. Accounting Subledger prepares accounting entries from gift transactions, using accounting sets that map designations, payment methods, and statuses to ledger accounts, and jobs that produce transaction journals. The foundation's finance team imports those journals into its own general ledger, which remains the system of record. Salesforce Help describes the subledger as included with Fundraising in Education Cloud. Design the accounting set with the controller before go-live so that no gift posts without a mapping.
Can donors manage their own recurring gifts without calling us?
Salesforce Help documents a Donor Support Agent under Agentforce for Fundraising in Education Cloud that lets donors pause, resume, close, or change the amount of a gift commitment with a recurring schedule, from a donor portal on an Experience Cloud site. It requires the Agentforce add-on and a cloned permission set with access to gift commitments. Without the agent, the Fundraising Operations app gives staff guided flows for the same tasks. Either way, the commitment and its schedule are standard Fundraising records.