• Ready for review

    • Contacts/Accounts - PosiEd

    Owned by Mike French (Unlicensed)
    Last updated: Nov 12, 2024 by Darren Wright
    5 min read

    Account - Record Types 

    PosiEd supports several custom record types that are used for specific functions.

    These include: 

    • Educational Institution (School)

    • Department 

    • House 

    • Billing

    Each of these record types except Billing has a custom setting associated with it, in which you can define the ID of the record type you have created for your org. For example, if you wish the Educational Institution record type to be ‘School’, create a record type called ‘School’ and set this record type ID in the Educational Institution Record Type custom setting. 

    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. 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 (Educational Institution Only)

    PosiEd allows you to associate multiple Timetable Structures to a single Educational Institution. 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.

    For example, if you have a Timetable Structure established for 2024 and at the end of this year you want to begin loading data for 2025, the best method may be to: 

    • ensure there are no active users in the system, then; 

    • change the Default Timetable Structure to the 2025 record 

    • perform any LISS functions such as Publish Bell Times and Timetable etc 

    • set the Default Timetable Structure back to 2024 until the 2024 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.   

    There are two techniques available as standard, which you can disable if you prefer to define your own methodology. 

    The Session object has a field called Roll Marking Status. This field controls whether the roll marking is required or optional i.e. if a session’s roll marking status is set to Required the staff member is required to mark the roll and if they fail to do so they will have their session highlighted on the Unmarked Roll Report component for follow up.

    Typically schools will use one of two methods of determining which sessions will require roll marking; from the Cohort or through the Bell Time object as follows.  

    Cohort - The class itself will define this e.g. academic classes require this but extracurricular do not. This is further supported by a variety of defaulting Mark Roll fields on the Subject and Subject Groups respectively. By setting a Subject’s mark roll to Required, all associated Subject Groups will in turn have their mark roll value set to Required, which will in turn set all associated Cohort Mark Roll values to Required. 

    If the school’s Mark Roll Defaults value is then set to Cohort, then when Generate Calendar is executed, all Sessions created for those cohorts will have the Mark Roll Status set to Required. Otherwise they will be set to Optional.

    Bell Time - The Bell Time record of each session will define the Session’s Mark Roll Status. This is useful in situations where you might only mark the roll in Period 1.

    To accomplish this, review the Bell Time object and find the Period 1 records for each day of the week and set their Mark Roll value to Required.

    When the Generate Calendar or Publish Daily Data is executed, each session will be evaluated to see if they are associated with a period that requires Mark Roll Status to be set to Required; if so it will do so. Otherwise it will be left as Optional.

    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.

    In several areas such as the Contact/Student Record object pairings there are a number of automations that ensure data gets replicated between these objects. The challenge is that if all these automations are active at one time, a circular reference can be created. For example, updating a Contact’s email address will cause an update to the Student’s Record. The update of the Student Record might cause an update to the Contact record to be triggered and so on. 

    To prevent this situation, and to specify the “Source of Truth”, 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.  

    If this setting is set to Published then it is assumed that PosiEd is the source of truth and that the automations will push updates down the tree. 

    If this field is set to a value of None, neither set of automations will execute. This is ideal if you are doing a full data load from another source and are taking full responsibility for the rolling up or down of data.

    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.