Attendance Management for Multi-Campus Institutions

Roles are scoped to one campus, a set of campuses, or the whole group. A campus principal sees only their campus; a regional director sees a defined set of campuses; the group CFO or superintendent sees all campuses read-only for operational data and read-write for finance and HR. Cross-campus transfers require both source-campus and destination-campus admin approval, logged immutably for audit. Permission templates ship for common organisational structures (school chain HQ, region, campus; university system chancellor, campus president, dean; MAT executive, hub, academy). Custom role hierarchies are configured without code.

Yes. Biometric fingerprint, RFID card tap, QR code scan, and manual entry are configured per campus based on local culture and infrastructure. A Mumbai campus running biometric, a Manila campus running QR through the student app, a Dubai campus running RFID card tap at classroom entry, and a rural Kenya campus running manual paper-to-app entry all coexist in the same deployment. Group reports normalise the data into the same attendance fields (present, absent, late, excused, medical) regardless of capture method. Campus head decides what fits local operational reality.

Group admin defines a policy at group level (for example, updating the exam-eligibility attendance threshold from 75% to 80% for UGC-affiliated colleges, or updating the ADA absence-code mapping for a US district). The policy propagates to all campuses on a scheduled effective date, giving campus admins time to communicate the change locally. Campus admins can override with documented exceptions (a campus operating in a conflict zone may need a lower threshold with regional-director approval, or a magnet school may run a longer year) logged for group visibility and audit. This avoids the drift trap where every campus quietly ends up with slightly different rules over 5 years.

Yes. Each campus has a country and region setting that drives local statutory reporting: UK campuses get DfE attendance codes (authorised, unauthorised, late), US campuses get Average Daily Attendance (ADA) and Average Daily Membership (ADM) calculations for state funding under NCES definitions, Indian campuses get UGC or AICTE compliance for post-secondary and state-board attendance formats for K-12, UAE campuses get KHDA (Dubai) and ADEK (Abu Dhabi) reporting, Australian campuses get MySchool and state-department reporting, and Canadian campuses get provincial ministry reporting. The group reporting layer normalises for executive view while campus-level statutory reporting stays legally correct per jurisdiction.

No. Community Edition has no per-student and no per-campus fee, ever. Enterprise Edition is priced per concurrent staff user at $19 per user per month starting, not per campus or per student, so adding the 30th campus costs only marginal infrastructure (CPU, RAM, storage, database capacity). This is materially different from proprietary SIS at $5-$20 per student per year multiplied across a 50-campus, 30,000-student group. Typical annual savings at that scale are $150,000-$600,000 versus PowerSchool, Blackbaud K-12, or Infinite Campus. Sources: PowerSchool and Blackbaud K-12 published pricing tiers, EDUCAUSE Core Data Service, and district procurement filings.

When a student transfers from campus A to campus B within the same group, the source-campus admin initiates the transfer with reason code (family relocation, disciplinary transfer, grade-level program transition, medical). The destination-campus admin approves. The full student record (admissions history, attendance percentage year-to-date, grade history, exam results, fee ledger with any outstanding balance, health records, IEP or 504 accommodations in the US, EHCP in the UK, or equivalent SEND documentation elsewhere) transfers atomically. The destination campus picks up the year-to-date attendance percentage against the destination-campus calendar and rules; the source campus retains a read-only historical view. FERPA (US), GDPR (EU), and equivalent record-retention rules are satisfied by the immutable audit log of the transfer event.

Deployment architecture supports horizontal scaling: PostgreSQL primary with read replicas for reporting workloads, application-tier auto-scaling for peak-attendance-window traffic (morning check-in), and object storage for attachment files (medical certificates, absence notes, ID photos). Database partitioning by campus keeps per-campus query latency flat as the group grows. The largest published multi-campus deployment on a single OpenEduCat instance is 300+ campuses. For groups above 300 campuses, a federated architecture with per-region instances syncing to a group-level analytics warehouse is a common pattern; the platform supports both single-instance and federated deployment.

A 20-30 campus group typically completes migration in 6-9 months with campus-by-campus phased rollout. Phase 1 (months 1-2) covers group-level platform provisioning, data-model configuration (which fields are group-level versus campus-level), role hierarchy setup, and 1-2 pilot campus migrations. Phase 2 (months 3-5) covers rollout to a first wave of 5-8 campuses, refinement of the migration playbook, and pilot cross-campus policy rollout. Phase 3 (months 6-9) covers the remaining campuses in waves of 5-8 per month. A 100+ campus international group typically runs a 12-18 month phased rollout aligned to regional academic-year boundaries. Change management (training campus admins, aligning group and campus expectations) is the determining factor, not the platform technology.