What this module is for
Manage student attendance, staff attendance, working-day logic, and biometric/RFID/QR device scans.
Prerequisites
- Current academic session
- Class and section data
- Working-day policy configured
- Attendance permissions assigned
Main screens
Step-by-step workflows
Mark student attendance
- Open Attendance > Student Attendance.
- Select session, class, section, and date.
- Confirm the date is a valid working day.
- Mark attendance for listed students.
- Save or finalize according to your school workflow.
Apply a device scan
- Add an attendance device.
- Use Scan Kiosk or device API to submit a credential.
- Review the scan event.
- Map an unmatched credential to one active student or staff member.
- Apply the matched scan once.
- Re-scan for the same date should be protected from duplicates.
Operational detail
Permission checkpoints
- Student attendance, staff attendance, reports, devices, mappings, scan events, and apply actions are permission checked separately.
- Device operators can submit scans only through approved kiosk or device routes.
- Attendance reports expose only the school/session data allowed for the signed-in user.
Field guidance
Select the operational date being marked. The date is checked against calendar holidays and weekly-off settings.
For student attendance, these fields decide the eligible student list and historical placement for that date.
Use the school-approved status for each student or staff member, such as present, absent, leave, or late where available.
Finalized attendance is treated as authoritative for registers, reports, profile cards, and downstream calculations.
RFID, QR, or biometric-style credentials are stored as protected identity mappings and are shown only in masked form.
Unmatched scans need mapping. Matched scans can be reviewed and applied once for the selected person and date.
Validation and system feedback
- The selected date must be a valid working day unless the workflow explicitly supports the exception.
- Students and staff must be active and belong to the authenticated school.
- Duplicate attendance for the same person and date is blocked by the canonical workflow.
- Credential mappings must be unique and scoped to the correct school and person type.
Common mistakes to avoid
- Marking attendance against the wrong class or historical section.
- Trying to apply an unmapped scan event.
- Expecting a repeated same-day scan to create another attendance row.
- Using device credentials in screenshots or support messages without masking them.
Recommended next steps
Screenshot plan
Final public screenshots will use synthetic QA data only. Sensitive values such as names, phone numbers, emails, admission numbers, document numbers, credentials, cookies, tokens, and internal IDs must be removed or redacted.
Important safety notes
Use normal Schoolixa workflows
Public docs explain user workflows only. They do not expose internal IDs, direct database operations, credentials, provider prompts, or private system configuration. Permission visibility in the interface does not replace server-side permission checks.