Schools and training providers use Salesforce to hold one record per learner, from first inquiry to alumni giving. Education Cloud is the Salesforce product built for this work. It covers recruitment, admissions, advising, advancement and institutional communications. It sits beside your student information system and learning platform rather than replacing them. The practical job is deciding which records live where, who may see them, and which workflow to fix first.
Which institutions is this guide written for?
It targets colleges and universities, private K-12 schools, and providers of training or continuing education. Each group shares a learner lifecycle, but the pressure points differ.
A university usually cares most about enrollment yield, advising load and alumni support. A private school often centres on family relationships, tuition-driven admissions and re-enrollment each year. A training company thinks in cohorts, course sales, employer sponsors and repeat learners. Salesforce can serve all three, yet the object design and phase one scope should not be identical.
One disclosure before the detail. Abstrakt has not published an education case study, so this guide describes general Salesforce design practice rather than lessons from named education projects.
What is Education Cloud, and how does it differ from EDA?
Education Cloud is the current Salesforce industry product for education, and its data model is built on person accounts. EDA, the Education Data Architecture, is the older free managed package that many institutions still run.
EDA models a student as a contact attached to an administrative account. Education Cloud instead treats each learner as a person account and adds standard objects for programs, courses and enrollment. Examples in the Salesforce documentation include LearningProgram, LearnerProgram, LearningCourse, CourseOffering and CourseOfferingParticipant. Object names and licensing change between releases, so check the current data model reference before you design.
Salesforce has indicated that EDA remains supported, but the two models are not meant to run side by side in one org. That makes the choice a real architecture decision. A new institution usually starts on Education Cloud. An institution with years of EDA customisation should plan a deliberate move rather than a partial blend.
| Design question | EDA (legacy package) | Education Cloud |
|---|---|---|
| How is a learner stored? | Contact with an administrative account | Person account |
| Where do programs and courses live? | Custom objects inside the managed package | Standard objects in the platform data model |
| How is it delivered? | Free managed package installed into an org | Licensed industry product; confirm editions with your Salesforce account team |
| Can both run in one org? | Not intended alongside Education Cloud | Not intended alongside EDA |
| Where does new AI tooling land first? | Check release notes; newer features may not target it | Salesforce positions its education AI features here |
How should the recruitment and admissions funnel be modelled?
Treat the funnel as stages on an application record tied to the learner, not as a status field on the person. That keeps a history when someone applies twice or to several programs.
A typical sequence runs inquiry, prospect, applicant, admitted, deposited or committed, then enrolled. Name the stages in your own vocabulary and write down the exit criteria for each.
- Capture the source of every inquiry: event, web form, list purchase, referral, employer partner or agent.
- Store program interest separately from the application, because interest often shifts before anyone applies.
- For K-12, relate parents and guardians to the applicant and mark who holds decision authority.
- For training providers, treat an employer sponsor as its own account linked to each learner it funds.
How can Service Cloud support student success and advising?
Use cases for requests that need an owner and a resolution, and use advising appointments for planned conversations. Mixing the two makes both hard to report on.
Student requests reach many offices: financial aid, registrar, housing, IT, disability services. A shared case model routes each request to the right queue and keeps the history visible to authorised staff. Advisers then see recent cases, holds and outreach on one learner page before a meeting.
Early alerts deserve care. A signal from the learning platform, such as missed assignments, can open an outreach task for an adviser. Agree who owns each alert type, how quickly someone responds, and when an alert is closed. Otherwise alerts pile up and staff stop trusting them.
Where do advancement and alumni fundraising fit?
Education Cloud includes advancement capability, so gifts, pledges and campaigns can sit on the same person record as the student history. That link is the main reason to keep fundraising in the same org.
Confusion arises because Nonprofit Cloud offers similar fundraising objects. Nonprofit Cloud is built for charities whose core work is programs and donors. Education Cloud is built around learners, with advancement as one department. Institutions already running NPSP or Nonprofit Cloud for giving should map which product owns gifts before migrating anything. Confirm the current fundraising features in each product with your Salesforce account team, since packaging has shifted over recent releases.
Whichever product you choose, define household and relationship rules early. Parents, spouses, alumni couples and corporate matching gifts all affect how giving totals are credited.
How should Salesforce connect to the SIS and LMS?
Let the student information system stay the source of truth for official academic records. Salesforce should receive the fields that drive engagement, not a full copy of the registrar database.
| System category | Usually owns | Send to Salesforce | Send back from Salesforce |
|---|---|---|---|
| Student information system | Official enrollment, grades, holds, degree audit | Enrollment status, program, term, holds that affect outreach | Admission decisions and deposit status, where the SIS allows |
| Learning management system | Course content, submissions, grade books | Engagement signals such as last login or missed work | Rarely anything; keep the flow one-way |
| Application or portal platform | Application forms and document upload | Application stages and checklist status | Program lists and decision letters |
| Finance or payments system | Tuition billing and payments | Deposit and balance flags only | Nothing, in most designs |
| Event and email tools | Registration and send history | Attendance and engagement | Audience lists |
Agree a matching key before building any sync. A stable student ID from the SIS, stored as an external ID in Salesforce, prevents duplicate learners. Decide how prospects without a student ID are matched once the SIS issues one. Integration middleware or native connectors both work; the design choices matter more than the tool.
What should consent and FERPA awareness change in the design?
They should change who can see which fields and which messages can be sent. This section is design guidance, not legal advice, so involve your compliance office and counsel.
In the United States, FERPA governs access to many student education records. Other regions and age groups bring their own privacy rules. Children's data in K-12 settings needs particular care. Salesforce gives you the controls, but your institution decides the policy.
- Classify fields by sensitivity and restrict academic and financial data with permission sets and field-level security.
- Record directory-information opt-outs and honour them in every report, list view and export.
- Keep channel-level consent for email and text, noting when and how each learner opted in.
- Log who may speak for a learner, such as a parent granted access, and when that access ends.
- Review sharing rules each term, because staff move between offices and access tends to accumulate.
How do marketing journeys work across the student lifecycle?
Build journeys around a learner's stage and program, and let stage changes in Salesforce trigger them. Marketing Cloud can run the sends; which edition fits depends on your licensing.
Useful journeys include inquiry nurture by program, application completion reminders, admitted-student yield sequences and orientation onboarding. Alumni journeys cover events, volunteering and giving appeals.
Keep ownership clear. When admissions, student affairs and advancement all send email, learners receive too much of it. Set shared frequency rules and one suppression list, and give one team authority to resolve conflicts.
Can AI help with student communications safely?
Yes, when a person reviews what the AI drafts before it reaches a learner or family. Start with staff-facing assistance rather than autonomous replies.
Good early uses include drafting replies to routine admissions questions and summarising recent cases before an advising meeting. Suggesting next steps on a stalled application is another. Agentforce and the education AI features Salesforce promotes can support these patterns; confirm availability for your edition. Ground each response in approved policy content and limit what student data the model can read.
Which reports tell leadership whether the system is working?
Start with the enrollment funnel and retention, because leaders already ask about both. Add advising and advancement measures once the core data is trusted.
- Funnel conversion by stage, program, term and inquiry source, with counts rather than percentages alone.
- Time spent at each admissions stage and the number of files waiting on missing items.
- Yield from admitted to enrolled, split by program and by scholarship offer where relevant.
- Term-to-term retention and persistence, compared with advising contact and open cases.
- Case volume and resolution time by office, to show where students wait longest.
- Alumni participation and giving by class year, once advancement is live.
Retention figures usually originate in the SIS. State the definition on every dashboard so offices stop arguing about the number.
Which errors derail education Salesforce projects?
Most problems come from unclear ownership of data and processes, not from missing features. The following show up repeatedly in higher education and training settings.
- Copying the whole SIS into Salesforce, then struggling to keep two academic records consistent.
- Letting each office build its own contact fields, so the same learner looks different by department.
- Choosing between EDA and Education Cloud late, after custom objects already depend on one model.
- Skipping consent design and discovering later that lists include learners who opted out.
- Launching every department at once instead of proving value in one office first.
What belongs in an education phase one?
Pick one funnel or service area, the learner record beneath it, and the single integration it needs. For most institutions that is recruitment and admissions, fed by the SIS for program and term data.
- Confirm the data model choice: Education Cloud, or a documented reason to remain on EDA.
- Define the learner, guardian and sponsor relationships you need on day one.
- Model application stages, checklist items and inquiry sources for your priority programs.
- Build the SIS matching key and a limited, well-tested sync of enrollment status.
- Set up permission sets, field-level security and consent capture before any data loads.
- Deliver funnel dashboards that admissions leaders review in their regular meetings.
