Education Cloud (EDC) offers a range of additional capabilities above and beyond the standard SalesCloud Sales Cloud 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
...
PosiEd K-12
The PosiEd App is designed to work with or without the presence of Salesforce's Education Cloud (EDC). Its optional child package, PosiEd K-12 extends PosiEd’s capabilities to support a variety of functions necessary for running a K-12 school including Markbook, LISS integration and more. This package also leverages objects in Education Cloud and so has a dependency on it. This means that while PosiEd can exist without EDC, if you choose to implement the PosiEd K12 App on top of PosiEd. You will also require Education Cloud to be activated in your org.
This section describes a number of interactions and differences between PosiEd K-12 and EDC Objects and functions. You should familiarise yourself with EDC's architecture prior to reading this section.
You may have noticed that in some areas of EDC objects appear to overlap or have the same functions as certain objects in PosiEd and PosiEd K-12. Let's review these areas.
Academic Term vs Timetable Term
The EDC Academic Term object is used to define the duration and nature of the term enrollment period for students. It is used to direct the enrollment process and Academic Term Enrollments are associated with an Academic Term record. An Academic Term is usually defined to cover the entire school year (although part years terms can also be used).
The Timetable Term object's function however has more to do with timetable functions and the various cohorts that are associated with a specific timetable. Usually there is an Annual Timetable Term for year long subjects and cohorts, but there are also usually Semester, Term and even special Timetable Terms to cover durations such as sports seasons, which may even cross the boundaries of annual academic terms.
Each Cohort that uses timetabling must have both a Timetable Structure and Timetable Term reference associated with it.
Another example, where this might be important is where you are running multiple programs for students within an Academic Term. For example, an HSC program might be slightly different to an IIB or an RTO program in their Timetable Structures, however the enrollment process would still cover the same school year, i.e., Academic Term.
To simplify the management of these two objects PosiEd K-12 includes an automation [Under development] such that if you create a Timetable Term record with a term type of Academic Year, it will automatically create an Academic Term record for you with the same date range and associate it with that Timetable Term record. This saves creating the two records separately and will help you keep them in sync.
Subject Offerings vs Course Offerings
The PosiEd base package includes the objects Subject and Subject Offering, where a Subject is typically an academic class e.g., “Year 8 Math” and a Subject Offering is an instance of that subject delivered in a school year, eg. “Year 8 Math 2024”.
From the Subject Offering one or more cohorts are created representing each individual class, e.g. 2024 Year 8 Math Class A etc.
Education Cloud includes the objects Learning Course
...
Employee object
...
Day Attendance Summary calculations scoping – use DPE
...
Reportcard Generation
Grade Levels and Enrolments
INSERT 1734 HERE
Course Offering Participant versus and Course Offering. These objects connect to EDC's Learning architecture, which also supports Learning Programs.
If you are using PosiEd K-12 and EDC, the Learning Course program effectively supersedes the Subject object and the Course Offering object supersedes the Subject Offering object.
The Cohort object is designed to work with either Subject Offering or Course Offering and when PosiEd K-12 is installed and configured the page layouts and settings should be such that the Subject and Subject Offering objects are hidden.
Course Offering Participant vs Cohort Member
The Course Offering Participant Object object from EDC links a student contact student’s Account to a particular Course Offering e.g., 2024 Year 8 Math in 2024 the . The same record has an association with the Academic Term Enrollment objectsobject. 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 Cohort a student is associated with this . This function is performed by the Cohort Member Object object instead - since the Cohort is the specific class e.g., Year 2024 Year 8 Math Class 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 lookup to Course Offering Participant to link the two together, and an automation to automatically create a Course Offering Participant record and link link it whenever a Cohort Member record is created [Under development]. This means you need only create a Cohort Member record to a student, so for a each 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 classspecific Cohort. This means that if, for example, a student moves from 1 one cohort to another, they can remain enrolled in the same Course Offering course offering throughout this process since Academic Reporting Assessments . Since academic reporting and most assessments are done at the course offering level. You 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?To be done
Employee object
Day Attendance Summary calculations scoping – use DPE
Reportcard Generation
Grade Levels and Enrolments