Skip to main content
All help topics

For admins

The University plugin: what it is and who it is for

Most course platforms model a shop: a catalog, a buyer, a receipt. A university is not a shop. It has programmes with regulations, candidates with enrolment numbers, terms that open and close, examinations somebody must be able to defend at an appeal, and records that outlive the software. The University plugin adds that second model alongside the first, and it is installed per workspace — so a workspace that teaches yoga never sees a word about invigilation.

Last updated Aug 28, 2026

The plugin is off until you install it. Nothing about it appears in the sidebar, and its entire API is closed, until an administrator turns it on — so the ordinary product stays uncluttered for the workspaces that will never need a degree programme.

The plugin store showing the University card: its description, a list of what it adds, links to the documentation, the license tiers at ₹1,49,000 and ₹3,99,000, and buttons to start a 14-day trial or talk to us.
The plugin, before anything is installed — priced, with the documentation linked and a trial one click away.
Just under two minutes, recorded in the running product: admitting an intake from a spreadsheet, inviting it, moving it up a semester, the teacher’s question bank and invigilation, and what a candidate sits in front of.

What it adds

  • Programmes and regulations — duration in semesters, total credits, the internal/external mark split, minimum attendance, elective groups and prerequisites.
  • Admissions — candidates admitted against a programme and an entry semester, each given an enrolment number: generated as programme code + year + sequence (BCA20260001), or supplied by you if your institution has its own numbering.
  • Question bank and paper assembly — a pool of questions with difficulty and topic, and a blueprint that draws a randomised paper per candidate from it.
  • Proctored examinations — the paper is assembled and graded on the server, the candidate's browser never holds the answer key, and the sitting leaves an evidence trail.
  • Attendance, results and revaluation — attendance recorded as sessions held against sessions attended, marks entered against separate internal and external minimums, results published and then correctable.
  • Transcripts, marksheets and degrees — issued as PDFs with a verification code an employer can check without an account.
  • Institutional sign-in — staff and students sign in with the credentials your directory already issues.
The University plugin card during a trial, showing a panel that reads 'Trial running — 14 days left' and a note that nothing built during the trial is deleted when it ends.
During the evaluation. Build real programmes with a real cohort — none of it is deleted when the trial ends.

Who does what

The plugin does not use the flat owner/instructor/student roles the rest of the product runs on. A university has a chain of authority, and marks are the thing it exists to protect, so the roles are scoped and separated: a head of department publishes their own department and nobody else's, and the person who marks a script is not the person who makes that mark final.

  • Exam controller — owns the examination process end to end: authoring papers and the question bank, invigilating, voiding a sitting, entering marks, publishing results and revaluing them.
  • Registrar — admissions and records: registrations, enrolment numbers, marksheets and transcripts, and creating programmes. Note the deliberate gap — a registrar does NOT publish results.
  • Head of department — their own department, end to end short of voiding: papers, invigilation, mark entry, publication and programme structure.
  • Evaluator — enters marks, and nothing else. Specifically NOT publication: the person who marks a script must not be the person who decides the mark is final.
  • Invigilator — watches live sittings and flags incidents. Never sees or changes a mark.
  • Coordinator — read-only oversight of the sittings on their programmes. Changes nothing.
  • Candidate — sits examinations and sees their own results and documents, and nobody else's.
Roles stack. Somebody can hold both registrar and exam controller, and their capabilities add up — which is how a small institution gives one person the whole job without inventing a seventh role.
Scope is enforced on the server, not by hiding buttons. A head of department who calls the publish endpoint directly for another department is refused, and the refusal is written to the audit log.
The Institutional sign-in screen, showing the redirect URI to give an identity provider and the fields for connecting an OpenID Connect directory including the email domain allowlist.
Institutional sign-in. The redirect URI is shown up front — hunting for it is the commonest reason a first connection fails.

Built to the UGC ODL regulations

The regulations are encoded as rules the software enforces, not as a checklist you tick. Where a rule is a number, you set it per programme and the system holds you to it.

  • Credit-weighted SGPA and CGPA on the UGC ten-point scale, computed from credits and grade points rather than a simple average.
  • Separate internal and external minimums — a candidate who clears the aggregate but fails the external minimum has not passed, and the software says which.
  • Maximum duration — a candidature lapses at double the programme duration, and the system tracks the lapse date from the entry semester.
  • Credit-transfer cap — the share of a programme that may be brought in from elsewhere is capped per programme; a transfer that would breach it is refused with the arithmetic shown.
  • Minimum attendance — recorded as sessions attended against sessions held, with detention applied against the threshold you set.

What this is not

It is not a full university ERP. There is no fee-collection ledger, no hostel or transport module, no payroll, and no admission-test engine. It covers the academic spine — programme, candidate, examination, result, record — and it integrates with what you already run for the rest.

Do we have to move our whole institution onto this?
No. The academic spine works against the roster you already have, and institutional sign-in means staff and students keep the credentials your directory issues. Most institutions run it alongside an existing ERP and use it for the teaching, examination and record layer.
Can we try it before buying?
Yes — one click starts a 14-day evaluation with the full plugin, no card and no call. Use it properly: set up a real programme and a real cohort rather than throwaway data, because nothing you build during the trial is deleted when it ends. If you buy afterwards, it is all still there exactly as you left it. One trial per workspace; if you need longer, ask and we will extend it.
Is it a subscription?
No. The University plugin is a one-time license — ₹1,49,000 for a single domain, ₹3,99,000 for five. There is no renewal and no per-student fee. Optional updates and support are ₹30,000 a year, and the license stays valid whether or not you take them.
What happens when the trial ends?
The screens close and the API stops, exactly as if the plugin had been removed. Nothing is deleted, and nothing reaches your students: an examination already in progress finishes, candidates keep seeing their own results, and any document you issued during the trial keeps verifying.
What happens to our data if we stop using it?
Nothing is deleted. Removing the plugin hides the screens and closes the API; every programme, registration, result and issued document stays exactly where it was, and reinstalling brings the workspace back as it was. Marksheets you have already issued keep verifying regardless — a document in somebody's hand must never stop being checkable because of a billing change.

Related