---
title: "Education Cloud: What Admissions Data Should an AI Agent Use?"
description: "A technical guide to Salesforce Education Cloud admissions data for Irish institutions: what an AI recruitment agent should read and write under GDPR."
url: "https://www.skolbot.ai/en-IE/blog/education-cloud-admissions-data-ai-agent"
language: "en"
dateModified: "2026-09-25"
---

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

Updated on September 25, 2026

A technical guide to Salesforce Education Cloud admissions data for Irish institutions: what an AI recruitment agent should read and write under GDPR.

## 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)](https://github.com/SalesforceFoundation/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)](https://www.dataprotection.ie), 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](https://help.salesforce.com/s/articleView?id=sfdo.eda_explained.htm) 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](https://help.salesforce.com/s/articleView?id=sfdo.EDA_Program_Enrollment.htm). 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](https://www.salesforce.com/agentforce/use-cases/education/recruitment-admissions/) 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.

| Data category | Relevant Education Cloud objects | Agent reads | Agent writes | Why |
|---|---|---|---|---|
| Identity and contact details | Contact, Account | Yes | Yes (create/update on new enquiry) | Prevents duplicate contact records and routes the conversation |
| Programme interest and application stage | Applicant, Program Enrollment, Application Stage Definition | Yes | Yes (log interest, advance stage per agreed rules) | The core job of a recruitment agent |
| Marketing consent and communication preference | Contact fields, consent records | Yes | Yes (record opt-in/opt-out with timestamp) | Establishes a documented lawful basis for follow-up contact under GDPR |
| Enquiry and engagement history | Case, Activity, or a custom engagement object | Yes | Yes (append new interactions) | Feeds lead scoring and gives advisers context before a call |
| Application decisions and reviews | Application Decision, Application Review | Read-only at most | No | An admissions office or committee's judgement call, not an automated one |
| Academic records, transcripts, Leaving Cert detail | Academic Certification, Course Connection, Case (sensitive types) | No, by default | No | Sensitive category data with no recruitment-stage justification |
| Financial aid and SUSI grant detail | Student Financials objects | No, by default | No | High-sensitivity individual data a recruitment conversation doesn't need |

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](https://www.dataprotection.ie) 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](https://www.cao.ie) 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](https://www.qqi.ie), which both accredits institutions and validates individual programmes in Ireland, and the [HEA](https://www.hea.ie), 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 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](https://www.skolbot.ai/en-IE/blog/recruit-more-students-higher-education). If your team is still comparing CRM platforms rather than configuring one you already own, our [CRM comparison for higher education](https://www.skolbot.ai/en-IE/blog/crm-higher-education-comparison) covers Salesforce Education Cloud alongside Slate, Element451, and HubSpot. Once the data is flowing correctly, [lead scoring for student recruitment](https://www.skolbot.ai/en-IE/blog/lead-scoring-student-recruitment-schools) 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.

---

<a href="/en-IE/demo" className="cta-button">Try Skolbot on your school in 30 seconds</a>

## FAQ

### Does an AI recruitment agent need full CRM access to be useful?

No. The categories that make a recruitment agent genuinely useful — identity, programme interest, consent, and enquiry history — are a small subset of Education Cloud's full schema. Full access adds GDPR exposure without adding recruitment capability.

### Can an AI agent update the Application Stage Definition object directly?

It can, within an agreed set of rules — for example, moving a record from "enquiry" to "application started" once a prospect confirms a CAO application submission. It shouldn't record an Application Decision; that call belongs to admissions staff, particularly for restricted-entry courses assessed partly on HPAT or portfolio results.

### Is it GDPR-compliant to let a chatbot write to Salesforce Education Cloud?

It can be, provided the lawful basis for each data category is documented, a Data Processing Agreement is in place with the vendor, and the agent's access is scoped rather than blanket. The [DPC's guidance for organisations](https://www.dataprotection.ie) is the reference point for Irish institutions building this out.

### How does CAO change what an agent needs to collect itself?

Since most Irish undergraduate applications flow through the [CAO](https://www.cao.ie), Leaving Certificate results, points, and course preferences are already captured centrally. An AI recruitment agent should read that data to personalise a conversation, not ask a prospect to re-supply information the CAO already holds.

### What's the difference between EDA and Salesforce Education Cloud?

EDA is the open-source data model — Affiliation, Program Enrollment, Course Connection, and the rest — underlying education-specific Salesforce products. Education Cloud is the commercial product built on EDA, with the Recruitment and Admissions layer (Applicant, Application Decision, Application Timeline) added specifically for the admissions funnel.