Salesforce for Higher Education: Clouds, Modules, Data Model, and Buying Well

Salesforce for higher education means Education Cloud (Agentforce Education), a paid product built on Person Accounts and standard learning objects, with five modules covering admissions, academic operations, student success, advancement, and student financials, plus Salesforce Commerce for selling courses online. It sits beside the student information system. ElevateActual implements it standard-first, one scoped phase at a time.

What Is Salesforce Education Cloud?

Education Cloud is Salesforce's industry product for colleges and universities. It is a paid product on the Salesforce Platform that adds a standard data model for learners, programs, courses, applications, and gifts, plus consoles, portals, and automation built for the people who run an institution. Since Dreamforce 2025 Salesforce has also called it Agentforce Education and, in places, Agentforce 360 for Education; Salesforce's own guide opens with "Salesforce Education Cloud, now known as Agentforce Education." Salesforce Help articles still say Education Cloud as of October 2026, and so does this guide.

The product is distinct from the Education Data Architecture (EDA), the free managed package many institutions installed before Education Cloud existed. They are different data models, and an institution runs one or the other; the table below covers what that means.

The simplest way to think about Education Cloud: it is the record of every person's relationship with the institution, from first inquiry to last gift, in one database. The student information system keeps the transcript. Education Cloud keeps the relationship. For the commerce side of that relationship, read Salesforce Commerce for higher education; for individual terms, the Salesforce higher education glossary.

What Are the Five Education Cloud Modules, and Where Does Commerce Fit?

Salesforce's Education Cloud product page organizes the product into five modules. Each maps to an office on campus, and each can be implemented on its own.

• Recruitment and Admissions. Inquiry capture, applicant records, application review, decisions, and the applicant portal. Built on IndividualApplication with application timelines and decisions. Our recruitment and admissions page covers the build.
• Academic Operations. Programs, courses, offerings, terms, course registration on a learner portal, holds and blocks, and transfer credit evaluation. This module holds the learning data model described below.
• Student Success. Advisor and director consoles, care plans, alerts, success teams, watchlists, pulse checks, and planning tools for degrees, careers, and life goals, per Salesforce's student success documentation. See our student success page.
• Advancement and Alumni Relations. Alumni engagement, corporate relations, and native fundraising with gift entry, RFM scoring, and household naming, per the fundraising in Education Cloud documentation. See advancement.
• Student Financials. Fees modeled as Products, a learner account view, and a Salesforce Payments merchant account, per Student Financials on Salesforce Help.

Commerce is not one of the five, and the Education Cloud product page does not mention a storefront. That gap confuses buyers. Salesforce Commerce, meaning B2B or D2C Commerce running on the Salesforce Platform with an Experience Cloud storefront, is a separate license that connects to the Academic Operations objects so that a public purchase creates an enrollment. ElevateActual calls that combination Commerce on Core. It is what a continuing education or professional studies unit needs when the buyer is the public and payment comes first; see continuing education commerce.

Which Salesforce Product Fits Which Use Case?

Institutions rarely buy all of Salesforce at once. This table maps common use cases to the product that handles each and the office that will live in it.

Two notes. Experience Cloud carries every portal, whether applicant, learner, alumni, or storefront, and is licensed on its own Experience Cloud for Education pricing page. And the service desk row is not an education module: a public university's HR service center we built runs on Service Cloud, replacing a legacy ticketing tool, in the same org and on the same people records as the rest.

How Is the Education Cloud Learning Data Model Organized?

Every Education Cloud module reads from the same learning objects, and knowing their names makes vendor conversations shorter. Salesforce documents them in Model Program Offerings in Education Cloud.

• Account as a Person Account: the learner, applicant, alumnus, or donor. One record per person, carrying both the individual and the account.
• Learning: the subject matter being taught, independent of how it is packaged.
• LearningProgram: a degree, certificate, or noncredit program. Continuing education programs and CEUs use this object the same way degree programs do.
• LearningCourse: a course within a program.
• CourseOffering: a section of a course in a specific term, with dates, instructor, location, and capacity.
• AcademicTerm: the term or session the offering runs in.
• CourseOfferingParticipant: a learner's enrollment, waitlist, withdrawal, or completion in a section. This is the record a storefront checkout creates.
• LearnerPathway: the sequence of learning a person follows toward a credential.
• IndividualApplication: an application to a program, with timelines, decisions, and contingencies attached.

Student success adds care plans, alerts, and action plans on top of the Person Account. Advancement adds gift and commitment records. One Person Account connects all of it: the application, the enrollment, the advising case, and the gift are rows related to the same person. We keep to these objects and add custom ones only with a written reason, a stance explained in standard objects first. The commerce-specific walk-through is in the Education Cloud data model for continuing education.

What Is the Difference Between EDA and Education Cloud?

This is the question most institutions already on Salesforce ask first, because many of them installed EDA years ago. The short answer: EDA is a free managed package with its own account model, Education Cloud is a paid product with Person Accounts and standard objects, and Salesforce publishes a kit to move from one to the other.

Salesforce's Data Migration Kit documentation covers data, not custom code or the automations an institution built around EDA, so the move is a project rather than an upgrade. UNE Online's storefront project replaced an EDA plus Enrollment Rx stack with Education Cloud and Commerce on Core. Running that move without stopping operations is the subject of moving from EDA to Education Cloud without a data freeze, and the broader set of source platforms is in our migration guides.

What Does an Education Cloud Implementation Involve?

An implementation is a sequence of decisions, then a build, then a cutover. The decisions take longer than the build when left to the end, so we front-load them.

1. Structured discovery. Who the users are, which office owns which record, what the SIS remains the source of, and what success looks like in a sentence. Every ElevateActual engagement starts here, including the fixed-scope accelerators.
2. Data model decisions. Map the institution's programs, terms, and application types to the standard objects. Decide what, if anything, needs a custom field, and write down why.
3. Security model. Profiles, permission sets, sharing rules, and portal access: who can see an applicant's file, a student's alert, a donor's giving history.
4. Migration. Historical applicants, enrollments, and gifts, cleaned and loaded, per our data migration checklist.
5. Integration. The SIS first, through supported APIs or a staging table, never direct database writes; then the LMS, the payment processor, and marketing. See SIS integration patterns for Banner, Colleague, and Jenzabar.
6. Portals and automation. Applicant, learner, or storefront sites in Experience Cloud, with the business logic in Flow and Platform Events rather than code.
7. User acceptance, training, and go-live. Scripted acceptance tests with the people who will use the system, training by role, and a cutover date with a rollback plan.

How Long Does Each Scope Take?

Timelines depend on scope, data condition, and integration approvals more than on the software. These are the planning ranges we use, in months, as of October 2026.

Three reference points from our own work: Unity Environmental University's public storefront went from kickoff to go-live in about three months; the DU Learning Exchange went from a June 2026 kickoff to a signed user acceptance and production deployment in September 2026; and a private health-sciences university with graduate and doctoral programs moved recruitment and admissions off TargetX onto standard Education Cloud, with an applicant portal, analytics dashboards, and a Jenzabar integration, live in summer 2026 ahead of its contract end. The reasoning behind each range is in Education Cloud implementation timeline by scope.

What Does Agentforce Add to Education Cloud?

Agentforce for Education is an add-on to Education Cloud that provides prebuilt agents for students, staff, and advancement. As of October 2026, Salesforce Help lists these agents: Student Recruitment (listed as beta on Salesforce Help), Transfer Credit (listed as beta on Salesforce Help), Student Advising Topics, Course Search, Student Goals, Student Financials, Financial Aid, Attendance Management, and Course Operations in Slack, plus Agentforce for Fundraising. Salesforce's Agentforce for Education product page describes eight prebuilt subagents: Student Recruitment, Financial Aid Inquiry, Transfer Credit, Course Search Support, Student Financials, Advising Support, Student Goal Guidance, and Philanthropic Research.

Two practical points. The agents require Education Cloud plus the Agentforce add-on, so an institution on EDA cannot use them. And every agent answers from the standard objects: Course Search reads Course Offerings, Student Financials reads the learner account, Advising Support reads the success records. An institution whose data lives in custom objects or spreadsheets gets an agent with nothing to say, which is the strongest argument for the standard-first stance in this guide. We cover the agents, their licensing, and what a continuing education unit can use today in Agentforce for higher education.

Is Salesforce a Good Fit for Community Colleges and Noncredit Units?

Yes, with two conditions: scope the first phase to one office with a measurable problem, and size it to the institution's procurement rules. Salesforce publishes a customer story about a multi-college community college district.

The noncredit and workforce side is where community colleges most often start, because it has a revenue problem to solve and no SIS footprint to protect. Workforce Pell funding began July 1, 2026, with final rules still pending and colleges finding that few programs qualify so far. Any program that does qualify will need clean enrollment and completion records to report against. A storefront that writes a Course Offering Participant at checkout produces those records as a by-product of selling the course.

Many community colleges have a procurement threshold above which a formal bid process applies. A fixed-scope accelerator can be sized to fit beneath it as a first phase, with later phases scoped on their own merits. That is a sequencing decision, not a shortcut, and it goes in the statement of work. The full discussion is in Salesforce for community colleges: noncredit, workforce, and the procurement cap.

What Should You Ask an Implementation Partner?

Salesforce lists many consulting partners, and most proposals will look alike. These checks separate them.

1. Partner tier and accreditation. ElevateActual is a Salesforce Select Partner and Education Cloud Accredited, listed on AppExchange as a consulting partner. Ask every bidder for both, and ask when the accreditation was earned.
2. Standard first. Ask how many custom objects the last three Education Cloud projects created, and ask for the written reasons. A partner who rebuilds the learning model in custom objects leaves you unable to use new Salesforce features or Agentforce agents.
3. Flow before code. Flow and Platform Events for record automation, Lightning Web Components for the user interface, Apex only where the platform requires it. Ask the partner to name the last thing they wrote in Apex and why. Our reasoning is in Flow-first automation for enrollment.
4. Who does the work. Ask for the names and delivery history of the people who will be in your working sessions, not the people in the sales meeting. The people on our team page are the people on the project.
5. Show it running before you sign. A partner who has built the thing can show you the thing: a working applicant portal, a storefront with a checkout you can complete, a success console with alerts. Slides describe intent; a running system describes capability. Our work page lists what we can show.
6. The SIS pattern. The answer should include supported APIs or staging tables and never direct database writes.
7. Life after go-live. Ask who answers the phone in month two and whether campus administrators will be able to run the system without the partner. Our delivery model is on how we deliver.

If you are writing a formal RFP, what a university RFP committee should ask a Salesforce partner turns these into scored requirements.

What Does the Full Lifecycle Look Like on Salesforce?

The reason to put higher education on one platform is the lifecycle; the reason to implement it one phase at a time is that each phase has to pay for itself. Here is the view we build toward.

• Admissions. An inquiry becomes a Person Account and an IndividualApplication; the applicant tracks next steps in a portal; the decision writes to the SIS. See recruitment and admissions.
• Commerce. The same person buys a noncredit course, a certificate, or a summer program on the storefront, and checkout writes the CourseOfferingParticipant. See continuing education commerce.
• Student success. Advisors see enrollments, alerts, and care plans for that person in one console and act before a problem becomes a withdrawal. See student success.
• Career. Career services tracks appointments, employer relationships, and mentoring against the same record. See career services.
• Giving. The alumnus gives, through the same storefront or a giving page, and the gift lands on the same Person Account that holds their application from years earlier. See advancement.

Each is a separate project with its own sponsor, and each can start first. Our three fixed-scope accelerators, Commerce, Recruitment and Admissions, and Student Success, exist so an institution can start with one office, go live in about two months, and extend from there.

Where this is heading is clear enough. Salesforce is putting its education investment into standard objects and agents that read them. Institutions that implement on those objects now get each new capability as configuration; institutions that rebuild the model in custom objects get a migration project. We would rather build the first kind.

Questions We Hear