Education Cloud (EDC) offers a range of additional capabilities above and beyond the standard SalesCloud when used in combination with PosiEd.
...
https://help.salesforce.com/s/articleView?id=sf.industries_common_features.htm&type=5
Data Processing Engine
Terms objects
Subject Offerings vs Course Offerings
Course Offering Participant vs Cohort Member
Employee object
Day Attendance Summary calculations scoping – use DPE
Reportcard Generation
Grade Levels and Enrolments
INSERT 1734 HERE
Course Offering Participant versus Cohort Member
The Course Offering Participant Object from EDC links a student contact to a particular Course Offering e.g., Year 8 Math in 2024 the same record has an association with the Academic Term Enrollment objects. This allows you to see all students within a Course Offering and within a specific Academic Term.
What this object does not allow you to do, however, is to see which individual class i.e,cohort? A student is associated with this function is performed by the Cohort Member Object instead since the Cohort is the specific class e.g., Year 8 Math A.
This means that for each student, you need both a Course Offering Participant and a Cohort Member record. Cohort Member has both a look up two Course Offering Participant to link the two together and an automation to automatically create a Course Offering Participant record and link it whenever a Cohort Member record is created. This means you need only create a Cohort Member record to a student, so for a student and the Course Offering Participant record will automatically be created for you.
The beauty of this arrangement is that participation in a Course Offering is super now separate to participation in a single class. This means that if, for example, a student moves from 1 cohort to another, they can remain enrolled in the same Course Offering throughout this process since Academic Reporting Assessments are done at the course offering level. You can maintain a continuity of relationship throughout whatever cohort changes you need to make.
Note to Mike rename the EDC customization guide section.
New section to be added after this section in the docs, a student records architecture.
Both PosiEd and Salesforce Education cloud are designed with one primary purpose in mind, to put the student first and foremost.
To that end both architectures are designed to provide immense levels of flexibility and detail even in the most complex multi school, multi campus environments. In most platforms, offering students flexibility to do things like enroll in more than one campus at a time, to move between classes without interrupting academic assessment, to provide innovative core structures such as IIB and RTO. In addition to HSC etc., have all come to the come with the price of compromise when it comes to the architecture and storage of data on those students. Schools often resort to notes and separate records to keep track of the sometimes complex details.
PosiEd Education Cloud is designed to cater for as many of these challenges as possible. With this in mind, please understand that as you review the architecture. Some of the architectural choices might not immediately appear obvious, so change that to the reasoning behind some of the architectural choices may not immediately appear obvious. There is a far greater depth of consideration for providing are highly flexible Student Record keeping architecture that will accommodate even the most complex School environments and unique needs.
With this in mind, let's consider how we create the records necessary to enroll and manage a student in the PosiEd Environment.
Below is a slightly stylized version ERD of a typical student. Note that it does not include other capabilities that are delivered on top of the standard PosiEd in K-12 applications such as well-being academic assessments, etc. At this point, we are just reviewing the core requirements.
The students and their family
The 1st and most obvious record is to create Contact Record for the student themselves, so change contact to person account. Here you will populate the student's primary contact details. Note that you do not yet have to specify anything related to items such as their grade level. House, etc. This will come later.
The second step is to create Person Account records for their family and career contacts. These can be associated with the student contact via contact, contact relationships. Review how relationships are to be optimally configured. How the cascading of contact details will work and how data import of these relationships can occur?