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

Which admissions data should an AI agent actually touch?

An AI recruitment agent connected to Salesforce Education Cloud should read and write a defined slice of the CRM — identity, program interest, marketing consent, and inquiry history — not the full schema. It has no reason to see transcripts, disciplinary case notes, or bursary and loan detail. That restriction belongs in a Salesforce permission set, not in a vendor's assurance that the agent behaves.

The question has a concrete answer 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 a registrar's office or an IT lead evaluating an AI agent against a Salesforce build, that separation is where scoping starts.

It also maps cleanly onto Canadian privacy obligations. Under the Personal Information Protection and Electronic Documents Act (PIPEDA), organizations must limit collection of personal information to what's identified for a specific purpose and retain it only as long as necessary for that purpose. An AI agent with open-ended access to fields it never uses to answer a prospect's question is difficult to justify against that principle — and in Quebec, Law 25 adds explicit requirements around automated decision-making and consent that go further still.

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," "staff member of Partner Organization Y" — and Salesforce's EDA documentation describes it as the connective layer of the model.

One detail matters before scoping an agent's access: 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 one doesn't already exist, and the two stay linked from then on, per Salesforce's Program Enrollment documentation. Practically, an agent writing an application-stage update doesn't also need direct write access to Affiliation — the platform handles 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 be drawn. Applicant and Application Stage Definition describe process. Application Decision and Application Review describe a judgment call, usually made by an admissions committee at the faculty or program level.

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 — a U15 research university, a smaller undergraduate-focused institution, and a college with a CEGEP feeder pipeline in Quebec will each draw these lines slightly differently.

Two rows deserve extra scrutiny. Application Decision is tempting to expose so the agent can confirm an offer directly, but that turns a marketing tool into a system of record for an admissions outcome that a faculty committee, not the CRM, actually owns. Financial aid detail is tempting because prospects ask about OSAP, provincial student aid, and bursaries constantly — but the agent can answer general funding-process questions from published content without opening an individual applicant's award file.

Why PIPEDA and Law 25 make data minimization the sensible default

PIPEDA's Principle 4.4 requires that personal information be retained only as long as necessary for the identified purpose, and Principle 4.7 requires safeguards appropriate to its sensitivity — the Office of the Privacy Commissioner of Canada treats both as core obligations, not aspirational guidance. An AI agent holding standing access to academic or financial records it never actually uses is hard to reconcile with either principle if a subject access request or a compliance review asks why that access existed.

Quebec institutions face an additional layer. Law 25 introduced explicit rights around automated decision-making, including a requirement to inform individuals when a decision is made "exclusively" by automated means and to explain the factors involved on request. Keeping the AI agent out of Application Decision entirely sidesteps this requirement for the recruitment use case altogether — the agent qualifies prospects and logs interest, but the decision itself stays a human one, made by people who can explain it if asked.

Provincial systems add a further wrinkle worth flagging to your Salesforce admin: an applicant coming through OUAC in Ontario, or through a provincial application centre elsewhere, arrives with structured data already collected by that body. There's rarely a reason for a recruitment agent to re-collect information the applicant has already disclosed through the provincial system — it should read enough to personalize a conversation, not duplicate the intake.

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 assert without specifics. 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 records because nobody thought to restrict it.

For the broader recruitment context this sits inside, see our guide to recruiting more students in Canadian 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 institution's privacy office 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 recruitment officer.
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, and confirm the exclusion explicitly if your institution operates under Law 25.
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 requests come in.