1. Purpose
The purpose of this document is to define the data fields, interface requirements, business logic, and integration details for the automated attendance synchronization and parent/guardian notification (“auto-notice”) system. This will enable the school to send timely attendance-alerts (e.g., for unexcused absences, tardies, or other custom triggers) to parent/guardian contacts based on student data and attendance data.
2. Scope
Sync of student demographic and contact information from the school’s Student Information System (SIS) into the auto-notice system.
Sync of attendance records (e.g., absent, tardy, unexcused, etc.).
Automated generation of notices/alerts (via email, SMS, or phone) to parent/guardian contacts when predefined attendance-criteria are met.
Ability for the school to extend or customize fields/triggers (for example: number of unexcused days, tardies, attendance %).
Maintain data accuracy, respect privacy/security, provide audit/logging of notifications.
3. Data Fields & Definitions
3.1 Required Minimum Fields
The only strictly required field for the sync is:
Student ID – Unique identifier for each student (as defined in the SIS).
From that minimum, the system must pull the following for each student to support meaningful auto-notices:
Field Name | Description |
Student ID | Unique student identifier. |
First Name | Student’s given name. |
Last Name | Student’s family name/surname. |
Parent/Guardian Contact – First Name | First name of primary parent/guardian. |
Parent/Guardian Contact – Last Name | Last name of primary parent/guardian. |
Parent/Guardian Contact – Email Address | Email address to send notification. |
Parent/Guardian Contact – Mobile Phone | SMS or mobile phone number. |
Parent/Guardian Contact – Home/Alternate Phone | (Optional) Additional phone number. |
3.2 Recommended Additional Fields
To give the school more flexibility and richer notice content (and support segmentation/reporting), we recommend including the following fields if available:
Field Name | Description |
Grade Level | Student’s grade (e.g., 9, 10, 11, 12). |
Homeroom/Advisor | The student’s assigned homeroom teacher or advisor. |
School Name / Campus | If multiple campuses, identify which. |
Date of Absence | The date when the absence/tardy occurred. |
Absence Type | e.g., “Unexcused”, “Excused”, “Tardy”, “Left Early”. |
Period/Class (if applicable) | Which class/period the absence/tardy occurred in. |
Total Days Unexcused | Cumulative count of unexcused absence days to date. |
Total Tardies | Cumulative count of tardies. |
Attendance % | Percentage of days present vs. days enrolled. |
Intervention Flag | Flag whether student is already under intervention. |
Parent Opt-in/Notification Preference | Whether the parent/guardian consents to SMS, email, phone. |
Note: Any field beyond the “required minimum” must be configured by the school themselves — Edlio will provide the mapping mechanism but the school is responsible for populating and maintaining any extra fields.
4. Data Sync Process & Frequency
Edlio will ingest a daily (or more frequent as configured) data feed (CSV, API, SFTP) from the SIS containing the student demographic/contact fields plus attendance records.
Attendance records should reflect absences/tardies for the given day (or period) and update cumulative fields (e.g., total unexcused days) as of that run.
Edlio will maintain audit logs of data ingest, validation errors, notices sent.
Recommended sync frequency: daily by XX:00 AM after attendance data is finalized for the prior day.
5. Auto-Notice Business Logic
5.1 Trigger Conditions
The school shall define one or more trigger rules for sending Edlio the attendance data. Example trigger types:
When a student records an unexcused absence on a given day.
When a student accumulates X unexcused absences in a term/week/month (e.g., 5 in a month).
When a student is tardy more than Y times (e.g., 3 tardies).
When the student’s attendance percentage falls below a threshold (e.g., < 90%).
Custom: e.g., consecutive absences, specific class absence, field-trip absence, etc.
5.2 Notice Content
Each notice will be templated by the users, but will include merge-fields to personalize. Based on your data being ingested, merge-fields will include:
Parent/Guardian First Name
Parent/Guardian Last Name
Student First Name
Student Last Name
5.3 Notice Methods & Channels
Primary channel: Automated phone call (if configured), SMS (mobile) and/or Email.
Failure logic: if SMS fails (invalid number/blocked), attempt email; if both fail, log and flag for manual follow-up.
Time of sending: Ideally after harmonized data ingest (e.g., midday) to ensure parents receive notice on the same day of absence.
Language handling: If parent preferred language is non-English, the system should deliver notice in that language (if translations provided). This comes from the home language code (ISO 639-1)
Include clear call to action: e.g., “Please call the attendance office at XXX if you believe this is in error.”
5.4 Multi-Student/Family Handling
A parent will be notified for each individual student absence or tardy
Edlio will avoid duplicate notices to the same parent contact for the same event.
5.5 Escalation / Follow-Up
If the trigger is cumulative (e.g., 5 unexcused absences) and no response is received within X days, escalate to additional channels (phone call) or notify a designated staff member (counselor/administrator).
Edlio will maintain a log of notice status (sent, delivered, failed).
The school may configure intervals for follow-up notices (e.g., reminder after 48 hours) and automatic generation of follow-up letters.
6. Reporting & Dashboards
The system shall provide real-time or near real-time dashboards and reports including:
Daily summary: Number of notices generated, by school/campus.
Student-level detail: list of students who triggered notices, and counts of absences/tardies.
Parent deliverability: Notices delivered vs failed, response receipts (if applicable).
Export capability: CSV, PDF of the above metrics.
7. Data Privacy & Security
All data transfers must use secure mechanisms (SFTP).
Access to the notice system and data should be role-based (e.g. Administrator).
Sensitive student data (contact info) must be stored encrypted at rest and in transit.
Edlio supports existing privacy policies (FERPA or local equivalents).
8. Implementation & Deployment
Test file: Receive a test file, verify mapping, trigger logic, and sample notice(s) to test parent contact(s). Edlio recommends a single-student test before full rollout
Go-live: After successful test, auto-notices can be used
9. Roles & Responsibilities
Party | Responsibilities |
School / District | Prepare and deliver data feed (student demographic, contact, attendance) in approved format; decide on trigger logic; define custom fields; monitor and manage parent contacts; act on escalations. |
Edlio | Receive and ingest data feed; validate data; apply business logic; send notices; maintain dashboard/reporting; provide training and support; maintain logs; ensure data security/compliance. |
Integration Team | Map SIS fields to notice system fields; schedule feed; handle any API or file-transfer issues; manage connectivity. |
Attendance/Student Services Staff | Review alerts, follow up with parents, respond to failed notices, handle escalations and manual communication. |
10. Change Management & Customization
Any additional fields beyond the recommended list (Section 3.2, Recommended Additional Fields) must be requested and configured by the school.
The trigger logic (Section 5, Auto-Notice Business Logic) is configurable: the school must define thresholds, escalation rules, and notification templates.
Template wording for notices must be approved by the school and localized if multiple languages.
The school must maintain documentation of any custom fields and update mapping if SIS fields change (e.g., parent contact info changes).