AI Agents
AI agents for higher education: the student-services agent on Education Cloud, and the decisions it never gets to make
A student at 11 p.m. the night before the registration deadline can't reach anyone, and there's a hold on their account they don't understand. That gap: 24/7 demand meeting a shrinking, overworked staff, is where a student-services agent earns its keep. Here's the Education Cloud data model it runs on, the enrollment-to-advising work it can own, and the regulated line where financial aid, admissions, and grades stay human.
It’s 11 p.m. the night before registration closes, and a student can’t add their last class. There’s a hold on the account (financial, advising, immunization, they’re not sure which) and the message says “contact your advisor,” who went home at five. The student refreshes the portal, emails an address that auto-replies with a 48-hour SLA, and either gives up for the night or adds to tomorrow’s phone queue. Multiply that by every deadline week, every aid-disbursement cycle, every start-of-term, and you have the shape of the problem higher ed keeps trying to staff its way out of and can’t.
The reason it can’t is structural, and it’s getting sharper. The number of traditional college-age students is projected to peak mid-decade and then decline for years, the “demographic cliff” every enrollment office is now planning around, so institutions are being asked to serve students better with fewer of them enrolling and less tuition to fund the staff who serve them. Meanwhile the work is relentlessly seasonal and overwhelmingly 24/7, and a 2026 EDUCAUSE review found AI use on campus is nearly universal while only about half of respondents were even aware of an institutional AI policy. That last point matters: agents are already showing up in higher ed whether or not anyone governed them. This post is the governed version: the student-services agent a university can deploy on Salesforce, the Education Cloud data it has to run on, the work it can own, and the bright line where a regulated decision stays with a human.
Why student services is a good agent problem
Strip away the sector specifics and student services has the exact profile agents are built for: high volume, deadline-driven, rule-bound, and mostly identical case to case. “What’s the hold on my account?” “Did you receive my transcript?” “What’s my balance and can I set up a payment plan?” “Am I eligible to register for this course?” These are the questions that flood a call center in the two weeks around every deadline and go dark in between, and they’re questions with deterministic answers sitting in a system of record, if only someone could retrieve them at 11 p.m.
That’s the near-term prize, and it’s the same lesson that holds across every vertical where agents have reached production first: the agent that clears production isn’t the glamorous autonomous decision-maker, it’s the one that makes the high-volume, high-frustration work disappear and hands the hard cases to a human with the context already assembled. In higher ed the hard cases are unusually consequential (an aid award, an admissions decision, an academic-standing call) which makes drawing the line early even more important. Get the routine 70% answered instantly and correctly, and you’ve freed your advisors and financial-aid counselors for the 30% that needs their judgment.
The data foundation decides everything, and it’s changed
Before any agent, the data model. This is where a lot of higher-ed Salesforce knowledge is out of date, so it’s worth being precise.
There are two Education Cloud data models, and they are not the same thing. The older one is EDA (Education Data Architecture): a community-driven managed package built on the standard Account and Contact model, with objects like Affiliation, Program Enrollment, and Course Connection. The newer one is Education Cloud built natively on the core Salesforce Platform, no managed package, which models the student as a Person Account and carries its own objects: Program Enrollment, Course Offering and Course Offering Participant (the new-model equivalent of EDA’s Course Connection), Academic Term and related session objects, an Application object for admissions, and a Student Financials set (Billing Account, Academic Order, Invoice, Payment). Advising is modeled on the Case object with Success Teams and Success Plans.
The critical thing: the new core-platform Education Cloud does not run on EDA. They use different foundations, Person Account versus Account/Contact, and an org uses one or the other, not both at once. EDA remains supported (Salesforce hasn’t announced a retirement), and plenty of institutions still run it, but the go-forward product is the core-platform model, and migrating between them is a real project, not a toggle. If you’re planning an agent, the first question isn’t “which topics”. It’s “which data model are we on,” because everything the agent grounds on hangs off that answer.
On top of whichever model you run, Data 360, renamed from Data Cloud at Dreamforce 2025, is the grounding layer that unifies student data from across your systems into the profile the agent reasons over. This is the same principle we’ve argued makes or breaks any agent: the data foundation decides the agent’s quality far more than any prompt does. An agent grounded on a clean, unified student record can answer “what’s my hold and how do I clear it” precisely; one pointed at fragmented, duplicated records will confidently tell a student about the wrong account. Which is why duplicate and low-quality records are the first thing to fix, not the last.
The work the agent can own
Here’s the student-facing chain an agent can handle, with a human for the hard cases. Salesforce has been shipping education-specific agent capability into exactly this space: release notes describe a Student Financials agent, a student-recruitment agent, transfer-credit estimates, and an advising/student-summary skill, most of which require admin setup rather than arriving switched on.
1. Triage inquiries and deflect FAQs. The highest-volume, lowest-risk win: the agent answers policy and process questions (deadlines, requirements, “how do I…”) grounded in your knowledge base rather than a generic FAQ, and routes anything it can’t resolve. This is knowledge-grounded deflection, and it’s where the 24/7 load lives.
2. Answer application and admissions status. “Did you get my transcript?” “What’s outstanding on my application?” The agent reads the application record and tells the prospect exactly what’s missing and by when. Note the word status. It reports where things stand; it does not decide the outcome.
3. Handle financial-account questions and payment plans. Grounded on the Student Financials objects, the agent shows a balance, breaks down fees, explains a charge, and helps set up a payment plan within policy. This is billing information and self-service: distinct, and this distinction is load-bearing, from a financial-aid award decision.
4. Navigate the financial-aid process. The agent can be a conversational checklist: which documents are missing, which deadlines are looming, where the application sits in the pipeline, when disbursement happens. What it must never do is determine eligibility or an award amount, more on that in the next section.
5. Answer registration eligibility and course questions. “Can I register for this course?” turns on prerequisites, holds, and standing the agent can read; “what fits my degree plan” it can help with. Salesforce also ships course-search and transfer-credit-estimate capability: again, an estimate to inform the student, not the registrar’s official evaluation.
6. Prep advisors and flag at-risk students. This is the highest-value assistive use. Grounding on Data 360’s real-time graph and the Student Success data model, the agent can synthesize an advising summary (GPA, credits, standing, recent activity) so an advisor walks into a meeting already briefed, and it can surface students crossing risk thresholds for proactive outreach. The agent assembles and recommends; the advisor advises.
7. Hand off with context. Anything outside the agent’s lane routes to the right human (financial-aid counselor, advisor, registrar) through Omni-Channel with the full context attached, so the student doesn’t start over. On the channels students use: messaging on the web and in the portal, SMS, and WhatsApp, deployed through Experience Cloud and routed by the same Omni-Channel engine as your human staff.
The line the agent never crosses
Higher ed is full of decisions that are regulated, high-stakes, or both, and the agent’s job is to prepare, recommend, and route them, never to make them. Four in particular stay firmly human:
- Financial-aid determinations. Eligibility and award amounts are Title IV territory, bound by federal methodology and institutional policy. An agent can chase missing documents and explain the process; it cannot decide what a student is awarded. Letting it near that decision is a compliance incident, not a feature.
- Admissions decisions. Admit/deny, scoring an essay, weighing a holistic file, committee judgment, not classifier output. The agent reports status and completeness; a human decides.
- Academic standing and grades. Probation, dismissal, grade disputes, degree conferral: these carry appeals rights and due-process expectations. The agent surfaces the data; it doesn’t set the status.
- Accommodations, Title IX, and conduct. Disability accommodations (ADA/Section 504), Title IX matters, and disciplinary outcomes are legally sensitive and often require confidential, human-led processes. These aren’t “hard topics” for the agent to attempt carefully. They’re topics it should recognize and escalate immediately.
The design pattern is the same human-in-the-loop discipline that governs any regulated agent: decide up front which decisions require a person, when they enter, and what they see, and build the escalation, don’t bolt it on. The agent that knows what it isn’t allowed to decide is the one you can trust to run 24/7.
FERPA and the access model: what gates the data
A student-services agent touches education records, which means FERPA is in scope from the first conversation, and it’s worth being exact about what the platform gives you, because the marketing overstates it.
Two mechanisms do the real work. First, the Einstein Trust Layer: PII masking before prompts leave Salesforce, zero data retention with the model provider, and auditable logging of prompts and responses. Second, and this is the one that gates which records the agent can see, the agent inherits Salesforce’s standard sharing and permission model. Org-wide defaults, sharing rules, the role hierarchy, permission sets, and field-level security all apply to the agent exactly as they apply to the user it’s acting for. That’s how a student-facing agent sees only that student’s own record while a staff-facing agent sees a caseload: it’s the same governance that ensures an agent only sees what the user is allowed to see, applied to an education record.
What you should not say, internally or to a review board, is that the agent is “FERPA-compliant out of the box.” No Salesforce product certification substantiates that, and FERPA compliance is an institutional responsibility built on these controls, not a checkbox the platform ticks for you. The honest framing: the Trust Layer and the sharing model give you the technical controls to build a FERPA-compliant deployment; scoping the agent’s access, disclosures, and consent to your institution’s obligations is work your team owns.
Where the SIS still lives
Be clear-eyed about the stack, because this is where higher-ed agent projects over-reach. Salesforce is not your student information system. The authoritative records for enrollment, grades, holds, and financial aid live in Ellucian Banner or Colleague, PeopleSoft Campus Solutions, or Workday Student, and those remain the systems of record. An agent built on Salesforce answers by reading that authoritative data and by acting within Salesforce (creating cases, tasks, and advising plans) not by becoming the SIS.
The integration reality: MuleSoft is the documented path, often via Ellucian’s Ethos layer for Banner and Colleague, with terms, programs, holds, and standing synced through APIs, Platform Events, or Change Data Capture. The pattern that works is asymmetric: the agent reads authoritative SIS data freely to answer questions, but real-time write-back into the SIS is the harder, more constrained direction and is usually mediated or batched rather than a live update from a chat. Design the agent to write into Salesforce and let governed integration reconcile with the SIS, not to poke the registrar’s database directly. (Salesforce does market Education Cloud as a “next-gen SIS,” which is a genuine option for institutions consolidating rather than integrating, but that’s a platform-replacement decision, not something an agent project should assume.)
Getting this boundary wrong is one more entry in the catalog of reasons agent projects fail: wrong system of record, ungrounded confidence, and a data foundation nobody cleaned first.
What decides whether it works
Four things bite in production:
- Duplicate and dirty records. A student who exists three times in your CRM gets three different answers. Unifying and deduplicating the student profile in Data 360 is a prerequisite, not a nice-to-have: the data-quality groundwork is the difference between an agent that helps and one that misinforms.
- Stale SIS reads. If the agent answers “your hold is cleared” from a Salesforce copy that lags the SIS by a day, you’ve created a worse experience than silence. Freshness requirements have to be explicit, and the agent should read the authoritative value at the moment it matters.
- Seasonal load. The whole point is surviving deadline week, so the agent and its integrations have to hold up under a concurrent spike, not just a clean one-to-one demo. An agent that’s brilliant in October and falls over during registration hasn’t solved the problem that mattered.
- Over-promising the scope. The fastest way to lose faculty and staff trust is an agent that confidently wanders into aid, admissions, or grades. Scope it tightly, make the escalation crisp, and let it be excellent at the routine work rather than mediocre across everything.
The takeaway
Higher ed is one of the clearest agent opportunities going, because the routine student-services load is high-volume, deadline-driven, and rule-bound, while the consequential decisions are few and well-defined. The pattern that works: get the data foundation right first (know which Education Cloud model you’re on, unify and dedupe the student profile in Data 360) then let an agent own inquiry triage, application and financial status, payment-plan self-service, aid-process navigation, registration eligibility, and advising prep, on the channels students use. Hold the aid determinations, admissions decisions, grades, and accommodations behind a human. Gate every record through the Trust Layer and the sharing model, and be honest that FERPA compliance is your institution’s job, not the platform’s. Keep the SIS as the system of record and let the agent read it, not replace it. Do that and the student staring at a hold at 11 p.m. gets a real answer, while your advisors spend their scarce hours on the students who need them.
Understanding the basics
What can an AI agent do for a college or university?
For students, it can answer the high-volume, 24/7 questions that flood a call center around every deadline: application and document status, account balances and payment-plan setup, financial-aid process navigation (which documents are missing, what’s due), course-registration eligibility, transfer-credit estimates, and general policy and how-to questions, all grounded in your real records rather than a static FAQ. For staff, it can prepare an advising summary before a meeting and flag at-risk students for proactive outreach. What it should not do is decide financial-aid awards, admissions outcomes, grades or academic standing, or accommodations, those stay human. The reliable near-term value is deflecting routine work and handing hard cases to a person with context already assembled.
Is Salesforce Agentforce for education FERPA compliant?
The platform gives you the controls to build a FERPA-compliant deployment, but “FERPA compliant out of the box” overstates it. There’s no product certification that makes compliance automatic. Two mechanisms do the work: the Einstein Trust Layer (PII masking, zero data retention with the model provider, audit logging) and Salesforce’s standard sharing and permission model, which the agent inherits so it can only see the records the acting user is entitled to. Configuring the agent’s access, disclosures, and consent to your institution’s FERPA obligations is work your team owns; the platform supports it rather than guaranteeing it.
Does an education agent replace our student information system?
No. Banner, Colleague, PeopleSoft Campus Solutions, or Workday Student remain the systems of record for enrollment, grades, holds, and aid. The agent reads that authoritative data (typically through MuleSoft, and via Ellucian’s Ethos layer for Banner and Colleague) to answer questions, and it writes into Salesforce (cases, tasks, advising plans) rather than pushing live updates back into the SIS, which is the harder, more constrained direction. Salesforce does offer Education Cloud as a “next-gen SIS” for institutions consolidating rather than integrating, but that’s a platform decision separate from deploying an agent.
What’s the difference between EDA and the new Education Cloud?
EDA (Education Data Architecture) is the older, community-driven managed package built on the standard Account and Contact model, with objects like Affiliation, Program Enrollment, and Course Connection. The newer Education Cloud is built natively on the core Salesforce Platform, no managed package, and models the student as a Person Account with objects like Program Enrollment, Course Offering, Course Offering Participant, Application, and a Student Financials set. They use different foundations and an org runs one or the other, not both. EDA is still supported with no announced retirement, but the core-platform Education Cloud is the go-forward product, and it’s the model you should confirm you’re on before designing an agent, because everything it grounds on depends on it.
Planning a student-services agent and trying to work out which Education Cloud model you’re on, how to unify the student record, and where the FERPA and decision boundaries go? Talk to us. Getting the data foundation and the human-in-the-loop right, so the agent is trusted at 11 p.m. and stays out of the decisions it shouldn’t touch, is exactly the work that makes it worth deploying. Our integration and Data 360 practice connects it to the SIS you already run.
