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 needs a narrow slice of the CRM, not the whole schema: identity, programme interest, marketing consent, and conversation history. It has no legitimate reason to see exam scripts, disciplinary case notes, or bursary detail. A well-scoped Salesforce permission set should enforce that boundary — the agent should not have to be trusted to self-restrict.

This matters because Education Cloud is not a flat contact database. It is 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 adds a further split between "who is applying" and "what decision has been made." An admissions or digital director evaluating an AI agent against this model has a genuinely answerable question: which of these objects should the agent read, which should it write, and which should stay off-limits by default.

For UK institutions running UCAS-fed pipelines through Slate, Salesforce, or another Education Cloud instance, this question sits alongside — not instead of — the usual UK GDPR data-minimisation obligation. The ICO expects processors to justify each category of personal data they hold, and an AI agent with standing access to every field in the CRM is hard to justify against that principle.

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, in particular, is the join between a Contact and an Account that represents things like "prospective student of Programme X" or "employee of Partner School Y" — Salesforce's own EDA documentation describes it as the connective tissue of the model.

One detail is worth knowing before anyone designs an agent's data access: Program Enrollment and Affiliation are kept in sync automatically. Saving a Contact's Program Enrollment record creates the corresponding Affiliation between that Contact and the academic programme if one does not already exist, and the two stay linked from then on, according to Salesforce's Program Enrollment documentation. Practically, that means an agent writing an application-stage update does not also need write access to Affiliation — the platform handles that link on its own.

Education Cloud's Recruitment and Admissions data model, built on top of EDA, adds a second layer specific to the funnel: Applicant, Application Decision, Application Review, Application Stage Definition, and Application Timeline. This is where the distinction that matters for an AI agent becomes explicit — Applicant and Application Stage Definition describe where someone is in the process; Application Decision and Application Review describe a judgement made about them, usually by an admissions committee or a named member of staff.

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

The table below sets out a working split, mapped to the objects above. It is a starting position for a data-governance conversation with your Salesforce admin, not a fixed spec — every institution's permission sets will differ.

Two rows carry most of the risk if they are done badly. Application Decision is tempting to expose to an agent so it can tell a prospect "you've been made an offer" — but that turns a marketing tool into a system of record for an admissions outcome, which is the wrong ownership model even before you consider error rates. Financial aid detail is tempting because prospects ask about funding constantly — but the agent can answer general funding questions from published content without reading anyone's individual award record.

Why data minimisation is the right default, not just the compliant one

The case for restricting an agent's scope is not purely a UK GDPR argument, though it is also that. The ICO's guidance for organisations building or buying AI is explicit that data minimisation applies to the training and operation of AI systems, not only to manual processing — an agent with standing read access to fields it never needs to answer a prospect's question is difficult to defend if a subject access request or an ICO audit asks you to justify that access.

There is also a practical argument that has nothing to do with regulators. A recruitment agent scoped to identity, programme interest, consent, and engagement history is easier to test, easier to explain to an admissions director, and easier to hand over to a new IT lead than one with implicit access to the entire Education Cloud schema. When something goes wrong — a wrong answer given to a prospect, a stage updated incorrectly — the smaller the object footprint, the faster the audit.

UCAS applicant data adds a further wrinkle worth flagging to your Salesforce admin: much of what a UCAS-mediated applicant has already disclosed (predicted grades, personal statement content) arrives through the UCAS feed rather than through direct conversation with your agent. There is rarely a reason for a recruitment agent to re-collect or re-expose that data — it should read enough of it to personalise a conversation, not re-process it as if it were new personal data the agent itself gathered.

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 programme they mention, the stage they appear to be at — gets enriched back into the CRM contact record, alongside a lead score the admissions team can act on.

The object-level detail of any given connector is a configuration question for your Salesforce admin and your vendor, worked out against your own permission sets and your own Education Cloud build. What should not be a configuration afterthought is the principle in the table above: an agent earns write access to programme interest, consent, and engagement history because that is its job, and it should not 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 UK higher education. If you are 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. And 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

Before granting any AI agent — Skolbot or otherwise — access to your Education Cloud org, work through this with your Salesforce admin and, where UK GDPR applies, your data protection lead:

1. Define the permission set explicitly. List the objects and fields the agent needs, object by object, rather than granting it the same profile as a human admissions user.
2. Separate read from write. An agent may legitimately need to read Application Stage Definition to give a relevant answer, without ever needing write access to it.
3. Exclude Application Decision and Application Review by default. Revisit this only if there is a specific, documented use case and sign-off from admissions leadership.
4. Exclude financial aid and academic record objects entirely unless a named, narrow exception is agreed and logged.
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, not just at implementation — scope tends to expand quietly as new requests come in.