Kinvolved Data

We'll start by describing at a high level what data to provide to Kinvolved, how to provide it, and how often it should be provided.

What data to provide

The following are the key entities that are typically required and provided by school districts to have a working Kinvovled system.

Schools: A list of schools is needed to do building-level messaging and attendance tracking. Schools are also used for access control. Provided as OneRoster org entities.
Terms: Terms are provided for each school as well as the district to indicate the start and end of the school year as well as each semester or trimester. These are critical for calculating things like absence rates. Provided as OneRoster academicSession entities.
Teachers/Staff: Teachers that are loaded and assigned to sections will be able to message students enrolled in those sections. Provided as OneRoster user entities.
Students: Students should be provided along with an SMS-capable phone number and preferred language if a district intends to communicate with them directly. Provided as OneRoster user entities.
Guardians: Parents or other guardians or relatives of a student. Should be provided along with SMS-capable phone number and preferred language. Provided as OneRoster user entities.

Warning

Note that we assume that a SMS number is in the SIS because the person has expressly given permission to be contacted using it--they have "opted-in" to district communications. The system will allow them to "opt out" if they don't want to continue to recieve SMS messages using Kinvolved.

Courses: Courses provide a way to group and organize sections. Provided as OneRoster course entities. Optional for districts only doing building-level communication based on daily attendance
Sections: A list of course sections is used to define the relationship between students and teachers. Teachers are only able to message students who are currently enrolled in an active section to which they are assigned. Provided as OneRoster class entities. Optional for districts only doing building-level communication based on daily attendance
Teacher Section Assignment: Assigment of a teacher to a section. Provided as OneRoster enrollment entities. Optional for districts only doing building-level communication based on daily attendance
Student Section Enrollment: Enrollment of a student in a section. Provided as OneRoster enrollment entities. Optional for districts only doing building-level communication based on daily attendance
Absence Codes: Absence codes for attendance of a student in a school for a particular day or a section for a particular period. Provided as Kinvolved OneRoster+ absenceCode entities.
Attendance: Attendance of a student in a school for a particular day or a section for a particular period. Provided as Kinvolved OneRoster+ attendance entities.

Info

Note that there are other data that are entered or modified directly in the Kinvolved system that are not sent like the above. A good example would be school calendars which are critical for attendance tracking since they identify things like holidays. These are modified directly in they system.

Ways to provide data

Kinvolved is designed to sync data from a school district student information system. There are 3 primary ways of ingesting data from a school district.

Rostering Options

CSV Push

The CSV Push approach relies on a district to export data from a SIS or similar system, format as OneRoster data and send it to Kinvolved.

API Pull

With the API Pull a job developed by Kinvolved and running on its servers makes a call directly to a district SIS to pull roster data. The SIS could either be hosted on a district network exposed to the Internet or SaaS hosted.

We would prefer to pull data using the industry standard OneRoster API but can also support pulling data from one of the follwing SIS: PowerSchool, Infinite Campus, Skyward, or Aeries.

Integrator Pull

In the Integrator Pull case a 3rd party is responsible for getting data from the SIS into a cloud-hosted service like Classlink or Clever. Kinvolved then pulls data from the integrator using either the OneRoster API or the Clever API. The benefit of this approach is that it typically also provides SSO with district systems.

How often to provide data

The frequency in which data is typically provided is either one-time, yearly, daily or hourly.

One-time: Some entities are essentially static and must be manually changed after they are initially created. Examples include schools and absence codes.
Yearly: Entities that change every year include things like terms and courses.
Daily: Entities that change daily include things like teachers, students, sections, and enrollments.
Hourly: The only entity that is typically sent hourly is attendance.