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, programme interest, marketing consent, and enquiry history — not the full schema. It has no reason to see academic transcripts, disciplinary case notes, or SUSI grant 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 a digital lead evaluating an AI agent against a Salesforce build, that separation is where scoping starts.

It also maps directly onto GDPR, which applies in Ireland as EU law — supplemented, not replaced, by the Irish Data Protection Act 2018. The Data Protection Commission (DPC), Ireland's supervisory authority and also the lead EU regulator for several major tech firms headquartered in Dublin, expects organisations to justify each category of personal data they hold under the data-minimisation principle. An AI agent with standing access to fields it never uses to answer a prospective student's question is hard to justify against that standard.

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 Programme 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 programme 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. Application Decision and Application Review describe a judgement call, usually made by an admissions office or a programme-level committee — restricted-entry courses like medicine, which factor in HPAT scores, are a clear example of a decision that needs to stay with named staff.

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 traditional university, a Technological University, and a private college will typically 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 outcome the admissions office — not the CRM — actually owns. Financial detail is tempting because prospects ask about the Student Contribution and SUSI eligibility constantly, but the agent can answer general funding-process questions from published content without ever opening an individual applicant's grant file.

Why GDPR makes data minimisation the default, not an afterthought

GDPR's data-minimisation principle, Article 5(1)(c), requires that personal data be "adequate, relevant and limited to what is necessary" for the purpose it's processed for. Because Ireland applies GDPR directly as an EU member state, this isn't a local adaptation of a foreign standard — it's the same regulation a French or German institution answers to, supplemented locally by the Data Protection Act 2018. The DPC's guidance for organisations treats an AI system's data access the same way it treats any other processing activity: justified by purpose, not by convenience.

CAO-mediated applicants add a wrinkle worth flagging to your Salesforce admin: much of what an applicant has already disclosed — Leaving Certificate subjects, points, course preferences — arrives through the CAO feed rather than through direct conversation with your agent. There's rarely a reason for a recruitment agent to re-collect or duplicate that data; it should read enough to personalise a conversation, not re-process it as if it were freshly gathered personal data.

QQI, which both accredits institutions and validates individual programmes in Ireland, and the HEA, which coordinates higher-education funding and governance, don't set CRM-specific data rules, but a documented, permission-set-level answer to "what can our AI agent see" is exactly the kind of evidence that supports institutional data-governance reporting to either body.

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, 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 programme 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 Irish 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 data protection 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 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, especially for restricted-entry programmes.
4. Exclude academic-record and financial-aid objects entirely, treating Leaving Cert detail and SUSI 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 an intake cycle. Scope tends to expand quietly as new requests come in.