Mark roll defaults
You've probably seen that each session Session can have a mark rolling status Mark Roll Status default value of either required Required or optional. If the value is optional, then the staff member does not have to complete the role i.e. an unmarked role will not be included in the today's unmarked rolls report. Other sessions will have a default mark roll status of required and if these sessions pass their end time without the mark roll status being set to complete then they will be included in the today's unmarked rolls list.
There are two ways that Posi Ed automatically sets the status of each session’s mark roll status and there is a third option available for a fully custom solution.
...
School level mark roll defaults
All cohorts Optional.
...
See here for details on this setting.
School Level Mark Roll Defaults
All Cohorts are associated with a particular Educational institution Institution account. If you look at the school's this account record , you will see an option to set mark roll defaults Mark Roll Defaults to either cohortCohort, Bell time Time or noneNone.
...
...
Mark Roll Defaults = Cohort
If Mark Roll Defaults is set to cohort Cohort then any sessions that are created by Posi Ed PosiEd either via the generate calendar Generate Calendar process or via the publish daily data Publish Daily Data process will have their mark roll default Mark Roll Default value reflect the default value set at the cohort level. Each cohort has its own mark roll Mark Roll field.
...
The value set in this field is usually defaulted by an equivalent field at the subject offering Subject Offering level which is usually defaulted to the same field at the subject Subject level i.e. usually all academic subjects might be set to mark roll required = Required whereas co-curricular subjects might be set to optionalOptional. This will propagate up the tree from subject Subject to subject offering Subject Offering to cohort Cohort and then subsequently to all sessions Sessions created for those cohortsCohorts.
This process only defaults the cohort Cohort and session Session values, both of which can be overridden in various circumstances , if required.
Mark Roll Defaults = Bell Time
If instead the school Mark roll default Roll Default value is set to bell time Bell Time then rather than look at the cohort Cohort when creating a session, the system will look at the associated Bell time Time record instead.
...
In this example, this particular bell time Bell Time record has a value of mark roll requiredMark Roll = Required, therefore all sessions associated with that Bell time Time will be set likewise. This approach is used when for example you want to mark the roll on the first period of the day and the first period after each recess or lunchtime, regardless of the type of cohort or subject.
Mark Roll Defaults = None
You have the option of disabling both of these features and controlling the mark roll default Mark Roll values yourself. In order to do this change the educational institutions mark roll default value to none. And no session Educational Institution's Mark Roll Default value to None, then no Session will automatically have their mark roll status Mark Roll Status set to requiredRequired. Instead, the school is required to establish automations or processes to control this process as required.
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.