Education Cloud: What Admissions Data Should an AI Agent Use?

Which admissions data should an AI agent actually touch?

An AI recruitment agent wired into Salesforce Education Cloud should read and write a specific slice of the CRM — identity, program interest, marketing consent, and inquiry history — and nothing beyond it by default. It has no legitimate reason to see transcripts, financial-aid award detail, or disciplinary case notes. That boundary should live in a Salesforce permission set, not in a vendor's promise to behave.

The question is answerable because Education Cloud isn't a flat contact list. It's built on the Education Data Architecture (EDA), an open-source model that already separates a person's identity from their academic relationships, and the Recruitment and Admissions layer on top of EDA further separates "where is this applicant in the funnel" from "what decision was made about them." For an enrollment management VP or a director of admissions technology evaluating an AI agent, that separation is the starting point for scoping access.

It also happens to line up with FERPA. The Family Educational Rights and Privacy Act protects education records and restricts disclosure of personally identifiable information from them without consent, per the U.S. Department of Education's Student Privacy Policy Office. An AI agent with standing access to fields it never needs to do its job is a harder position to defend if a FERPA compliance review — or a state attorney general acting under a state privacy law — asks why that access existed.

What Education Cloud's data model actually contains

Salesforce's EDA extends the standard Account and Contact objects with education-specific custom objects: Affiliation, Relationship, Program Enrollment, Course Connection, Academic Certification, Address, Attendance Event, Case, Course, Credential, and Education History. Affiliation is the join between a Contact and an Account — "prospective student of Program X," "employee of Partner Organization Y" — and Salesforce's EDA documentation describes it as the model's connective layer.

One implementation detail matters before anyone scopes an agent's permissions: Program Enrollment and Affiliation sync automatically. Saving a Contact's Program Enrollment record creates the matching Affiliation between that Contact and the academic program if it doesn't already exist, and the two stay linked afterward, according to Salesforce's own Program Enrollment documentation. An agent writing an application-stage update doesn't also need direct write access to Affiliation — the platform maintains that link on its own.

Built on top of EDA, Education Cloud's Recruitment and Admissions data model adds objects specific to the funnel: Applicant, Application Decision, Application Review, Application Stage Definition, and Application Timeline. This is exactly where the line for an AI agent should get drawn. Applicant and Application Stage Definition describe process — where someone is. Application Decision and Application Review describe a judgment call made by an admissions officer or committee.

What an AI admissions agent should read, write, and never touch

The table below is a starting position for a conversation with your Salesforce admin, not a fixed spec — every institution's org and permission sets differ, and community colleges, private liberal arts colleges, and large public research universities will draw these lines slightly differently.

Two rows deserve extra scrutiny. Application Decision is tempting to expose so the agent can tell a prospect their status directly — but that turns a marketing tool into a system of record for an admissions outcome, which shifts ownership away from the office actually accountable for that decision. Financial-aid detail is tempting because prospects ask about cost constantly, but the agent can answer general net-price and aid-process questions from published content without ever opening an individual student's award record.

Why FERPA makes data minimization the default, not an afterthought

FERPA's restriction applies to "education records" — records directly related to a student and maintained by the institution — and disclosure without consent is the exception that needs a legal basis, not the default. Directory information (name, major, dates of attendance) is treated differently from a transcript or a financial-aid file, and the Student Privacy Policy Office's FERPA guidance is the authoritative reference for where that line sits.

For an AI recruitment agent, most of what it handles at the inquiry and applicant stage — before a formal enrollment record exists — sits closer to directory-style information than to a protected education record. That changes the moment someone becomes an enrolled or accepted student with an academic file in the system. A permission set that made sense for a prospect at the top of the funnel can become inappropriate the moment Salesforce and your student information system start reflecting an actual education record, which is one reason the "never touch" row for academic records matters even for institutions confident about their FERPA posture at the inquiry stage.

State privacy laws add a second layer on top of FERPA, particularly for institutions operating in states with comprehensive consumer privacy statutes modeled on California's approach. Those laws generally require documented consent for marketing communications and give prospects rights to access or delete their data — both of which are easier to honor when the agent's write access is confined to a small, well-defined set of fields rather than scattered across the org.

How this connects to a chatbot like Skolbot in practice

Skolbot is designed as an AI layer that sits on top of a school's existing CRM rather than replacing it, with native connectors that include Salesforce among other platforms. In practice, that means each conversation a prospect has with the chatbot — the questions they ask, the program they mention, where they appear to be in their decision — gets enriched back into the CRM contact record, along with a lead score the admissions team can act on.

The field-level detail of any connector is a configuration question worked out with your Salesforce admin against your own permission sets and your own Education Cloud build, not something a vendor should hand-wave. What shouldn't be an afterthought is the principle in the table above: an agent earns write access to program interest, consent, and inquiry history because that's the job, and it should never default into read access to application decisions or financial-aid records because nobody thought to restrict it.

For the broader recruitment context this sits inside, see our guide to recruiting more students in US higher education. If your team is still comparing CRM platforms rather than configuring one you already own, our CRM comparison for higher education covers Salesforce Education Cloud alongside Slate, Element451, and HubSpot. Once the data is flowing correctly, lead scoring for student recruitment is the next practical step.

A checklist before connecting an AI agent to Education Cloud

Work through this with your Salesforce admin and your registrar or compliance officer before granting any AI agent — Skolbot or otherwise — access to your org:

1. Define the permission set explicitly, object by object, rather than granting the agent the same profile as a human admissions counselor.
2. Separate read from write. An agent may legitimately need to read Application Stage Definition without ever needing write access to it.
3. Exclude Application Decision and Application Review by default. Revisit only with a documented use case and sign-off from admissions leadership.
4. Exclude academic-record and financial-aid objects entirely, treating them as protected under FERPA regardless of how the underlying student file was created.
5. Log every write the agent makes, with a timestamp and the triggering conversation, so a human can audit what changed and why.
6. Review the permission set at least once a term. Scope tends to expand quietly as new use cases get requested.