Account - Record Types
PosiEd supports several custom record types that are used for specific functions.
...
Custom Settings can be accessed through Setup > Object Manager > Custom Settings > PosiEd Settings. Clients are able to define whatever other account records types as they wish, however as a minimum you should define these record types in order to support a variety of PosiEd functions.
...
Page layouts
In general most clients will prefer custom page layouts for each of the account record types they define. By default a PosiEd implementation will be delivered with page layouts for each of the provided record types outlined. Clients can modify these as they require, however it should be noted there are specific features on some page layouts which should be carried over from the suggested layouts, for example in the Educational Institution record type there is a Timetable tab that displays the Timetable Structure and related objects, while the Person account page layout includes certain packaged and unmanaged custom fields that may be helpful in a typical school environment.
...
Fields
Field - School Code (Educational Institution Only)
The School Code field on a school Account record is particularly important if you are utilising the LISS interface. LISS data sources (and other functions) rely on the School Code value to identify which school data transfers will be impacted. School code values must be unique and must match the school codes in your external applications.
Field - Default Timetable Structure Structure (Educational Institution Only)
PosiEd allows you to associate multiple Timetable Structures to a single Educational Institution or school. For . At various times, for example, at the end of a school year it will be necessary to create a new Timetable Structure and associated data, generally prior to the following year.
While a school can have multiple active Timetable Structures, for example for primary and secondary schools operating out of the same school account - the LISS interface needs to know which of these timetables it should operate with, at any point in time.
...
ensure there are no active users in the system, then;
change the Default Timetable Structure to the 2024 record
perform any LISS functions such as Publish Bell Times and Timetable etc
set the Default Timetable Structure back to 2023 until the 2023 timetable is complete.
Field - Mark Roll Defaults (Educational Institution Only)
The Mark Roll default setting allows you to define how a session knows whether marking the roll is required or not.
...
None - The final option is to set the Mark Roll Default to None, which means neither of the above processes will execute when Sessions are created. Instead, all Sessions will be created with a Mark Roll status of Optional and you can employ your own custom automations to modify these values as required.
Field - PosiEd State (Educational Institution Only)
PosiEd is capable of working with third party applications such as EdVal and using the LISS API to either subscribe to data from EdVal or publish data to it.
...
To prevent this situation, and to specify the Source “Source of TruthTruth”, a field on the Account object called PosiEd State has been introduced for use in the Educational Institution record type. If set to a value of Subscriber, then it is assumed that PosiEd is receiving data from an external source and will propagate updates up the tree of objects.
...
This setting is available at the Educational Institution level so that in multi-school environments different schools can have different states at any point in time.
Posi Ed state
In most school environments the Posi Ed platform does not operate alone. For example, it will frequently be used in conjunction with Timetabling products such as Edval and other systems that might push data into Posi Ed or pull data from it at various times.
For example, when establishing a new school in Posi Ed it is not uncommon to push a lot of the data for the school from an external system into Posi Ed then after the Posi Ed database has been set up, Posi Ed might frequently push updates back into these external applications.
Posi Ed includes a number of automations that assist with establishing data sets correctly as data is moved between Posi Ed and other applications. A good example of this is the movement of student data. In Salesforce/Posi Ed we store student data in two objects; Accounts and Student Record. The Account object is a standard Salesforce object and there should be one account record for each student in your database.The student record object is used to store data with regards to that students interaction with a specific school. In some Posi Ed environments multiple schools all use the same Posi Ed database and students may from time to time move between these schools. For example when progressing from a primary school to a high school. In such a case there would be two student records for the one student account record; one for the primary school and the other for the high school.As you can see, these two objects serve slightly different purposes, and yet it is vital that the data fields in each are kept In sync. This is why we have automations on both objects that cause the other to be updated. The problem with this approach is that these automations are triggered when a record is updated. Therefore if an update is made to the account record it will cause an update to occur on the student record which would cause another update to the account record etc etc. This type of loop needs to be prevented. For this reason there is a field on the account object used by all educational institution accounts to specify whether Posi Ed is in a publishing or subscribing state. In a subscriber state, Posi Ed is expecting to receive data from an external system such as LISS. In this state the student record is going to receive updates, which it will then push to the account object.
Conversely, if the Posi Ed state publisher, then it is expected that modifications may be made to the account object and these will be pushed to the student record so that they can be picked up by LISS.
When you are modifying or writing your own automations you should be aware of the Posi Ed state concept and include support for it where appropriate.