Salesforce Education Cloud Data Model, Explained in Plain English

The Education Cloud data model puts each person at the center as a person account, then connects them to what they apply for, enroll in and complete. Programs and courses describe what you offer, academic terms and course offerings describe when it runs, and enrollments and applications record each person's journey through it. Get those pieces right and reporting, automation and integrations all get easier.

This is the part of an Education Cloud project I spend the most time on. For the full project view, see what an Education Cloud implementation involves.

The people

• Person accounts. Each student, applicant or alum is a person account, which combines an account and a contact in one record. That keeps one record per person even as their role changes.
• Contact profiles and person education. Extra details about the person live in related records, including their education history from other schools.
• Relationships. Parents, guardians, mentors and recommenders connect to the student through relationship records, not extra fields.

The most common mistake I see is creating a new record each time a person's role changes. An applicant who becomes a student, then an alum, should stay one person.

What you offer

• Learning programs. The programs you run, like a scholarship cohort, a degree or a certificate.
• Learning courses. The courses or modules inside a program.
• Academic terms. The calendar: years, semesters or cohorts.
• Course offerings. A course running in a specific term.

Keeping "what" separate from "when" lets you report across years without rebuilding anything.

Each person's journey

• Individual applications. An application to a program, with its stage, reviewers and decision.
• Program enrollments. A person's enrollment in a program, with start and end dates and status.
• Course offering participants. A person's enrollment in a specific course offering, which is where attendance and grades usually connect.

Together these answer the questions boards and funders ask most: who applied, who was accepted, who enrolled, who finished and what happened next.

Design decisions that matter most

1. What counts as a program. Decide this early. It shapes every report you'll build.
2. How you define terms. Match your real calendar, not a generic one.
3. Where outcomes live. Graduation, persistence and alumni outcomes need a clear home, usually on the enrollment or a related record.
4. What stays standard. Use the standard objects wherever they fit. Custom objects are harder to upgrade and hand off.
5. How data comes in. Applications, imports and integrations should all land in the same structure.

How to tell if your data model needs work

• You have more than one record for the same student.
• Reports need manual cleanup before every board meeting.
• You've built custom objects for programs or enrollments.
• Nobody can say where outcomes are tracked.

FAQ

What is the Education Cloud data model?

It's the set of standard Salesforce objects for education: person accounts for people, plus objects for programs, courses, terms, applications and enrollments.

Does Education Cloud use person accounts?

Yes. Each learner is a person account, so one record follows them from applicant to alum.

Can a scholarship program use the Education Cloud data model?

Yes. A scholarship cohort maps well to a learning program, with applications for selection and program enrollments for each scholar.

Should we customize the data model?

Only where the standard objects truly don't fit. Every custom piece adds upkeep. If you're choosing help for this, my guide to choosing an Education Cloud partner covers what to ask.

If you want a second opinion on your Education Cloud design, let's talk.