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 enquiry history — not the whole schema. It has no reason to see academic transcripts, misconduct case notes, or HECS-HELP and scholarship detail. That restriction belongs in a Salesforce permission set, not in a vendor's assurance about how 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 director of student recruitment or a Salesforce platform owner evaluating an AI agent, that separation is where scoping should start.

It also lines up with Australian privacy law. The Privacy Act 1988 and the Australian Privacy Principles it sets out require organisations to collect only the personal information reasonably necessary for their functions, and to hold it securely for no longer than needed. An AI agent with open-ended access to fields it never uses to answer a prospective student's question is a hard position to defend if the Office of the Australian Information Commissioner (OAIC) ever asks an institution to account for that access.

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 Organisation Y" — and Salesforce's EDA documentation describes it as the model's connective layer.

One implementation 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 afterwards, per Salesforce's 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 be drawn. Applicant and Application Stage Definition describe process — where someone sits in the pipeline. Application Decision and Application Review describe a judgement call, typically made by a faculty admissions 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 — a Group of Eight research university and a regional or newer university will typically draw these lines slightly differently given the scale of their applicant pools.

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 outcome a faculty committee — not the CRM — actually owns. Financial detail is tempting because prospects ask about HECS-HELP, FEE-HELP, and scholarships constantly, but the agent can answer general funding-process questions from published content without ever opening an individual applicant's award file.

Why the Privacy Act makes data minimisation the sensible default

Australian Privacy Principle 3 limits the collection of personal information to what's reasonably necessary for the organisation's functions, and APP 11 requires reasonable steps to protect it and to destroy or de-identify it once it's no longer needed — the OAIC's APP guidelines set both out as core obligations for any organisation handling personal information, universities included. An AI agent holding standing access to academic or financial records it never actually uses is difficult to reconcile with either principle if a complaint or a compliance review asks an institution to justify that access.

TEQSA, the regulator for Australian higher education providers, doesn't set CRM-specific rules, but its threshold standards expect providers to have sound data governance and to protect the information they hold about current and prospective students. A documented, permission-set-level answer to "what can our AI agent see" is exactly the kind of evidence that supports a governance review, whether TEQSA-driven or internal.

Admissions bodies add a further wrinkle worth flagging to your Salesforce admin: an applicant coming through UAC, VTAC, QTAC, SATAC, or TISC arrives with structured data — ATAR, subject results, preferences — already collected by that state-based body. There's rarely a reason for a recruitment agent to re-collect information the applicant has already disclosed through the admissions centre; it should read enough to personalise 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 enquiry 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 Australian 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 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 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, treating ATAR detail, transcripts, and HECS-HELP records the same way.
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 semester. Scope tends to expand quietly as new requests come in.