Reason codes play a critical role in how attendance is recorded, calculated, and reported. While they are flexible, small configuration mistakes can lead to inaccurate data or unexpected reporting outcomes.
This article outlines best practices to follow and common pitfalls to avoid when managing reason codes in Orah.
Best Practices
1. Choose the Correct Reason Type
Reason types determine how attendance is counted.
Use Excused for approved absences (e.g. illness, medical appointments)
Use Unexcused for absences that should count against attendance
Use Not Expected when students are not meant to be in class (e.g. school trips, exam blocks)
Using the wrong reason type is the most common cause of inaccurate attendance rates.
2. Use Clear, Consistent Naming
Reason names should be easy for staff to understand and select.
Use descriptive names such as Late – Unexcused
Avoid vague or shortened labels
Keep naming conventions consistent across all reasons
Clear naming reduces mistakes during roll calls and pass creation.
3. Keep Reason Codes Aligned With Attendance Policy
Reason codes should reflect your school’s official attendance policy.
Avoid creating multiple reasons for the same scenario
Remove or retire unused reasons
Review reason codes at the start of each term or academic year
This helps ensure reporting remains consistent over time.
4. Use Role-Based Access Controls Thoughtfully
Not all staff should have access to all reason codes.
Restrict sensitive reasons (e.g. Truant / Cut Class) to senior roles
Allow broader access to common reasons (e.g. Illness)
Access controls prevent accidental misclassification and protect data integrity.
5. Be Careful When Changing Reason Types
Changing a reason’s type can affect how attendance data is calculated in dashboards and reports.
Renaming a reason is generally safe
Changing a reason type should be done intentionally and with awareness of the impact
Before making type changes, consider how they will affect historical reporting.
6. Configure Default Reasons Carefully
Default reasons are applied automatically and can affect large volumes of data.
Review default reasons on roll codes and pass types
Ensure defaults use the correct reason type
Test changes before applying them broadly
Incorrect defaults can silently skew attendance data.
7. Map Reason Codes Correctly for SIS Integrations
For schools using a Student Information System (SIS) integration:
Map each Orah reason to the appropriate SIS reason code
Review mappings when adding or editing reasons
Validate exports after making changes
Incorrect mappings can result in failed exports or mismatched data.
8. Plan Carefully When Migrating From an Older Model (Optional)
For schools migrating from a legacy attendance model to the reason-based model:
Ensure all roll codes and pass types have default reasons assigned before migrating
Review reason types carefully, as migration can affect how historical data is classified
Communicate changes to staff ahead of the switch
Migration cannot proceed if any roll codes or pass types are missing default reasons.
Common Pitfalls to Avoid
Marking most absences as Excused, masking attendance issues
Creating too many similar or overlapping reasons
Changing reason types without understanding reporting impact
Leaving sensitive reasons unrestricted
Forgetting to review defaults after policy changes
Final Checklist
Before finalising your setup, confirm that:
All reason codes have the correct reason type
Default reasons are applied appropriately
Sensitive reasons are restricted by role
SIS mappings are complete and accurate
Unused or duplicate reasons are removed
Wrap-Up
When configured correctly, reason codes help schools achieve:
Accurate and trustworthy attendance data
Clear, consistent reporting
Predictable behaviour across roll calls, passes, and exports
This completes the reason code setup guidance in Orah.