ParentPaperwork manages a significant amount of data from schools. This post is a summary of how the data is imported and the various options and features. It is designed to be read by school ICT staff and database administrators to gain an overview understanding of our import modules and processes. For further information or assistance please contact email@example.com.
What Student Information Systems (SIS) does ParentPapework work with?
ParentPaperwork has ingested data from student information systems including:
- PC School
How does ParentPaperwork Acquire Data?
Data is obtained by ParentPaperwork in a variety of ways:
- Direct SQL database connection
- Pulled from remote API
- FTP pushed to ParentPaperwork
- Files pushed to ParentPaperwork’s Files API
We really don’t mind how the data is acquired and we are happy to work with a school or a provider to find the best and most efficient method. No matter how the data is acquired it is brought into our import system in a common format and centrally processed by a set of modules that handle various aspects of the data.
How frequently do we update imported data?
Almost always we update data from imported sources on a daily basis. We have the engineering capability and capacity for a higher frequency, but we figure a second-by-second update in real time is not necessary, schools are comfortable that if they make a change in their SIS one day it will be in ParentPaperwork the next day.
What data do we import?
At a minimum we import the data necessary for ParentPaperwork to operate:
- studentId (the unique identifier from your system for the student)
- className (this will be the Student List they are allocated to initially)
- parentId (the unique identifier from your system for the parent)
- studentId (so we can link parent -> student)
- mobile phone (only if you are using our optional Two Factor Authentication system or want SMS notifications enabled)
Additionally we can import further data:
Student Attributes are user-defined fields in the ParentPaperwork Student record, a school can have an unlimited number of Attributes defined, and we can import data to these fields. Student Attributes are able to be used as fields on ParentPaperwork forms; when the parent opens their form the fields will be pre-populated with the values we are holding. When the parent submits the form the Attributes in the Student record will be updated. We also offer a range of exports including one we nickname ‘just the things that changed’, a list of Students, their Attributes and only the values that were updated as part of the form submission. This makes Student Attributes ideal for tasks such as annual student record updates.
Obviously students don’t just fall into one group at school, there are home rooms, tutor groups, subject classes, sports teams. We can import these to ParentPaperwork to Student Lists so these groups are available. Some larger schools consequently have several hundred Student Lists.
We can keep the Users in ParentPaperwork updated with changes in the school SIS. Generally we are not able to access passwords from the SIS, which means this is only useful in a couple of scenarios:
- The school needs the Users in ParentPaperwork to be able to send the staff notifications about forms, for example to cc a read only copy of a Parent Slip. The staff member is not required to log into ParentPaperwork.
- The school is using single sign on (SSO) to ParentPaperwork, either Google or Office 365, and does not want automatic user creation enabled in ParentPaperwork (where we allow anyone who is authorised via the SSO to access ParentPaperwork. By syncing in a list of Staff we can restrict access to ParentPaperwork to just the list of Staff the school provides via the import.
What is the import logic?
Our foundation view is that the source of truth for a school’s data is its SIS, so ParentPaperwork needs to as closely mirror that as possible. We are also very conscious that there can be some complicated family situations that are liable to change from time to time, so keeping ParentPaperwork in sync with those is important.
The following describes the import logic we use for each type of data.
- Check if there are any student records in the import that are different to those in ParentPaperwork
- If the records are new Students, add them to ParentPaperwork
- If the records are existing Students, update the changes to ParentPaperwork
- Clear Students from any Student List named in the import that already exists in ParentPaperwork
- Update Students from the import to the Student Lists named in the import
- Optionally – clear students from any Student List created via import at any time, this deals with schools that don’t wish to maintain legacy Student Lists, it’s also useful for rollover at the beginning of a school year when we need to reset all Lists previously imported
- Optionally – mark any Students currently in ParentPaperwork as inactive that are not contained in the import – marking them inactive removes Students from default views and lists and means they and their parents cannot be sent forms. Very useful for preserving data to comply with document retention policies whilst ensuring the Students are not visible day to day unless specifically searched for
- Check for Student Attribute names in the import that are different to those in ParentPaperwork, and create new Student Attributes on the school account
- Update the Students with the values for those Attributes
- Check if there are any Attribute values in the import that are different to those in ParentPaperwork and update the Student records
- Note we log these changes as having come from an import, so we can differentiate with changes made via a User in ParentPaperwork, or a Parent submitting a form, so we can still generate exports of user/parent updates
- Check if there are any Parent Contacts records in the import that are different to those in ParentPaperwork
- If the records are new Contacts, add them to ParentPaperwork and link them to the relevant Students
- If the records are existing Contacts, update the changes to ParentPaperwork, examine the existing links to Students already in ParentPaperwork, and if different to the import, update
- Optionally – mark any Parent Contacts currently in ParentPaperwork as inactive that are not contained in the import – marking them inactive removes Contacts from default views and lists and means they cannot be sent forms. Very useful for preserving data to comply with document retention policies whilst ensuring the Contacts are not visible day to day unless specifically searched for
- Check the import for any new Student List names, create these Lists in ParentPaperwork and assign the relevant Students
- Check the import for any Student List names that already exist in ParentPaperwork, clear the Students already assigned to the List and update with the Students from the import
- If there are Student Lists which were previously created via import, but which are not in the current import, mark them as inactive.
How are imported records are displayed in ParentPaperwork?
Records that have been created via import are shown in ParentPaperwork with an icon and the text ‘Imported Record’.
Optionally, if a school chooses, we can enable a feature that warns a User attempting to edit a record with a popup message to let them know any changes they make might be overwritten by a subsequent import.
Can you prevent imported records being edited by Users?
We have a feature that can be enabled which prevents any adding or editing of Students, Student Lists and Parent Contacts by Users logged into ParentPaperwork. This was developed for schools who do not want any changes to records to be made in ParentPaperwork, rather only in the SIS and thence imported into ParentPaperwork.
Can I check if my imports are running?
When logged into ParentPaperwork click your User Name at the top right and select Integration Log. This will display a list of imports with date, source (for example your SIS) and the number of records processed.