Any campus system will take an admission and collect a fee. This one also carries no-dues clearance across every department that can hold a student back, invigilators who are not your employees, both income-tax regimes, bed-level hostel allocation, and a rest hour on the pre-primary timetable — because the necessities are where an institution actually loses its time.
Every capability on this page is checked against the source tree,
not against the roadmap.
Every institution gets its own HANA container. Inside it, every read and every
write is filtered again by branch scope, driven by the model rather than by
handler code, and fail-closed: a user with no resolvable scope sees nothing,
not everything. A row marked GLOBAL
is inherited read-only by every campus; a campus that needs a variant authors its own.
Not a shared table with a tenant column. Each subscribing institution is deployed into its own HDI container, so the isolation is physical, not a WHERE clause someone can forget.
A group running seven colleges under one society shares masters where it wants to and separates them where it must. The scope ladder runs GLOBAL then BRANCH, and nothing beyond it is claimed.
Settlors, trustees and office-bearers, statutory registrations, PAN/TAN, deed amendments and filed documents — modelled, versioned and auditable, because that is the layer that actually owns Indian colleges.
Open a module to read what it actually does, function by function. Filter by what kind of institute you run — a coaching centre does not need bed-level hostel allocation, and a polytechnic does not need an alumni events calendar — or search straight for the function you came to check.
A template is the shape of the week and nothing else — the periods and breaks of each weekday, with their times. No subjects, no teachers. A pre-primary day and a B.Tech day are different shapes, and the catalogue holds both; a campus picks one per section during year planning, and the periods are copied in as fresh, editable blocks on that section's timetable. Copied, not linked — so retiring a template never disturbs a section already running on it.
"Period 1, 09:00–09:45, Monday to Friday" is one action, not five, because a week is usually the same shape throughout. It is a convenience and not a constraint: every period and every break carries its own day and its own start and end, so one day can differ from the rest whenever it needs to.
A rest hour, a double-period laboratory and a flat school week are all just blocks on a day. Sections, teacher assignment and exam scheduling never fork by institution type, so nothing has to be rebuilt when a trust opens a pre-primary wing.
Overlapping blocks are caught when you save, a teacher's assignment carries its periods per week, and a room booked twice is the same question the space register already answers for clubs, meetings and exams. There is no solver that generates a clash-free week for you — templates are authored, not computed. Said plainly because it is the honest limit.
Every entry carries two independent dimensions: who it applies to — students, staff, parents — and how far down the hierarchy it reaches, from the whole campus to a single section. They are orthogonal, so staff of the Science department is one entry, not a workaround. An entry that carries hours shows its slot; one that does not is an all-day entry. Change any control below and watch the calendar resolve.
There is no single table holding every dated thing. A fact that has a real home keeps it, and the calendar reflects it — projected on read, never copied. So an exam rescheduled in the Exams app is already right here, because there was never a second copy to drift.
Facts that are purely a date, an audience and a scope — they have no richer home, so the calendar is their home. Terms, holidays, events, and recurring weekly-offs expanded into holidays as they are read.
Facts that own a lifecycle, an approval and a detail model of their own. They stay where they live and appear here read-only; clicking one takes you to the app that owns it rather than editing a duplicate.
Bus route schedules and statutory due-date trackers are deliberately left out. They are recurring operational schedules with their own semantics, not point events on a timeline — folding them in would make both worse.
They open it from an SMS, on a basic Android or an iPhone, often on a poor connection. They are not looking for a colourful page — they want the thing to work, first time, without installing anything. So it is one HTML file: no framework, no web fonts, no CDN, nothing to download. It loads, it does its job, and it gets out of the way.
Anita Sharma · Saraswati Vidyalaya
A teacher is very often also a parent. A parent very often has children at two institutions. A login is not an account at a school — it is one human, to whom schools attach relationships. Getting that distinction wrong is how one school locking an account locks the same person out of another one, and it is why the model below exists.
A fact about the person is global, and only the person may change it. A fact about the relationship is local, and only that school may change it.
A local decision must never write a global fact.
Ordered by how strongly they separate UniverseIT from the field. Every one is implemented and demonstrable — the line under each names the files it lives in.
Nothing downstream opens until its masters are marked complete — you cannot assign a fee before the ledger exists, or enrol a student before the course catalogue is frozen. The grid below is the real sequence, read left to right; the heavier the bar, the more you are setting up at that point. The Migration Cockpit groups its loadable objects along the same milestones, so a data load and a configuration step stay in step. Select a milestone to read it.
A new capability is never live because we shipped it. An administrator turns it on — globally, or for one campus, with the campus row winning. With neither row, the feature is off. Personas share one binary, and a login can hold several: a teacher is very often also a parent.
Toggle any switch to see how an institution actually configures the app — these are representative, not the whole catalogue. Features are actions, information or notifications, and some carry a recommended flag: a suggested starting set, never a pre-enabled one. The phone beside them is a preview; the full prototype opens in place, carrying every screen, the sub-roles, the live trip and the branding switch. It runs entirely inside this page.
A school office is a room with several people in it, all working on the same records at once, and a printer that never stops. These are the parts that decide whether the software is pleasant to use in March, not whether it demos well in June.
Opening a master for edit takes a lock on it. The second person is told who holds it rather than being allowed to start work that will be thrown away — and transactions written against a record mid-edit are refused too.
Every record carries a version token. Save a screen you opened before somebody else's change landed and the save is rejected outright, so a silent overwrite is not one of the things that can happen to you.
An unattended screen warns, then signs out — and releases every lock it was holding on the way. Otherwise one person going to lunch blocks a record for the afternoon.
Receipts, vouchers, certificates, letters, passes, payslips. A preview on screen and the downloaded PDF are rendered from the same document model, so what was checked is what gets filed — letterhead, line items, totals, the amount in words, and a signatory line.
The list you filtered is the list that exports, to PDF or to Excel — because the answer to "can I get this into a spreadsheet" decides whether people use the system or keep a parallel one.
Put a trust, a campus or an academic year into a negative status and nothing beneath it can be created, edited or deleted. Reads stay open — history and registers must remain viewable — and reactivating restores everything exactly as it stood.
Accreditation visits, statutory inspections and data-protection notices all ask the same question: can you show what happened, and who saw what? That answer is built into the data model, not bolted on as a log file.
When a member of staff opens a student's personal data, the access is recorded with a stated reason. Most systems can tell you who changed a mark. This one can tell you who looked.
Deletion is a platform-wide impossibility, not a policy people remember. Record-count snapshots run daily and drive a data-loss watchdog that notices when a table shrinks.
Recognises the Act's legitimate uses alongside consent — a fee demand rests on contract, a statutory return on legal obligation. Who may consent is derived daily from date of birth, so a student turning eighteen becomes their own data principal automatically.
Anti-ragging, POSH and RTI are first-class register types with their own investigation lifecycle — modelled by statute, not filed as categories on a generic ticket queue.
Fees, donations, club expenses and payroll all post real vouchers to a real ledger with cost and profit centres. A payroll run posts one compound voucher, not a document per credit.
Per-field runtime control (label, visible, mandatory, editable — as data), typed custom-field slots that stay inert and stripped from every read, write and export until enabled, and institution-wide multilingual name columns.
A capability list is only worth reading if it also says where it stops. These are in the model or in the back end and are not available to your users today.
The fastest way to judge whether this fits is to name the thing your current system makes you do on paper, and see whether it is already here.
UniverseIT is built and supported by SAPTECHS. Write to us about a demo, a requirement you want checked against the product, or anything already running at your institution.
Monday to Saturday, during working hours.
SAPTECHS Private Limited.
Every signed-in user can open a ticket from the app menu; your administrators answer them, and can escalate to us.