How Guru Kashi University runs 13 faculties and 200+ programmes on one Moodle LMS that stays in order
Guru Kashi University is a NAAC A++ campus university in Punjab with 9,095 students. With every faculty sharing one LMS, the risk was disorder: courses with no home, staff with the wrong access and no view for deans. Filari mapped the university's structure into Moodle, connected it to admissions and the CRM, built online exams, and runs it all on AWS.
one LMS
Many faculties and hundreds of programmes on one LMS can quickly become a maze of courses nobody owns.
A structure per faculty, an online examination system, API links to the university's own admissions system and CRM, and Filari running it all on AWS.
Every course has a place, an owner and a report.
Project snapshot
One Moodle LMS, online exams and managed AWS hosting for a multi-faculty campus
- Client
- Guru Kashi University, Talwandi Sabo, Punjab
- Industry
- Education > Universities
- Project type
- Moodle LMS setup, integrations and managed hosting
- Filari's role
- Structure, roles, online exams, API integrations, AWS operations
- Technology
- Moodle, AWS, APIs to the admissions system and CRM
- Timeline
- Since , build then managed service
When every faculty shares one LMS, order matters more than features
Guru Kashi University, one of the education institutions Filari works with, is in Talwandi Sabo, Bathinda, was established in 2011 under the Guru Kashi University Act of the Punjab Legislature, and grew from institutions founded by the Balaji Education Trust from 1997. It is NAAC A++ accredited and has 9,095 students from 25+ countries on a 100+ acre campus.
Its 200+ programmes run at Graduate, Post Graduate, Doctoral and Diploma level across 13 faculties, in areas such as Agriculture, Engineering, Management, Law, Pharmacy, Healthcare, Computer Applications and Education. Programmes range from B.Tech, MBA and B.Pharm to B.Sc (Hons.) Agriculture, B.A. LL.B. and B.P.Ed.
It is a campus university: lectures and labs happen in person, and the LMS carries material, assignments and quizzes around them. With 13 faculties on one Moodle LMS, the risk was not missing features. It was hundreds of courses with no clear home, staff with too much or too little access, and leaders with no way to see what was happening.
Courses created ad hoc end up in the wrong place, and students cannot find them.
One faculty's coordinator should not be able to edit another faculty's courses.
Enrolling every batch course by course does not scale across 200+ programmes.
Deans and quality teams need to see LMS use by faculty, not scroll through logs.
Does this sound like your university?
- Admitted students wait days for an LMS login because someone has to copy them across.
- Exam week is the week the LMS slows down or goes offline.
- Your server bill is the same in July as it is in exam month.
- No one can tell the Dean which courses nobody has opened.
Guru Kashi University had to solve all four. Here is how.
A place for every course, and an owner for every place
Four levels, each nested inside the one above. Pick a level to see who owns it.
Level 1 · University
One site, one login, one look
Every student and teacher at Guru Kashi University signs in to the same Moodle site and sees the same layout.
- Owned by LMS administrators
- Site-wide theme, settings and backups
Level 2 · Faculty
Each faculty gets its own branch
A faculty coordinator manages everything inside their branch, and nothing outside it.
- Coordinator role set at faculty level
- Creates courses and assigns teachers
Level 3 · Programme and semester
Grouped the way the timetable is
Within each faculty, courses sit under their programme and semester, so students find them the way they read their timetable.
- One folder per programme and semester
- Easy to roll over to the next session
Level 4 · Course and cohort
One home for each course
Each course sits in exactly one place, with its teacher and the student cohort for that programme, semester and section.
- Whole section enrolled through its cohort
- Starts from the university course template
Reports by faculty, so leaders see where e-learning is working
Because every course sits in a faculty branch, activity, submissions, completion and grades roll up by faculty and programme. A dean can spot a quiet course in week three, not at the end of the semester, and quality teams have evidence of e-learning use when they need it.
Illustration · course activity by faculty
Sample layout with no real data
Six parts of a campus-scale Moodle
A category tree per faculty
Every course has one homeUniversity, faculty, programme and semester levels, so a student finds a course the way they read the timetable.
Roles per faculty
Access that matches responsibilityFaculty coordinators manage their own branch; teachers edit their own courses; students see only what they are enrolled in; administrators see everything.
Cohort-based enrolment
A new batch enrolled in one stepStudents are grouped by programme, semester and section. Cohorts are filled from the university's application management system through the API, and each cohort enrols the whole group at once.
Course templates for every teacher
Consistent courses across facultiesNew courses start from a template with sections for syllabus, material, assignments and quizzes, so students see the same layout in every subject.
Assignments and quizzes around class
Blended, not replacedLectures and labs stay on campus. Teachers share notes, collect assignments and run quizzes on the LMS, with feedback and marks in one gradebook.
Reports for deans
Activity by faculty and programmeCourse activity, completion, submissions and grades filtered by faculty or programme, for regular reviews and quality evidence.
From admission to first class, without anyone re-typing a student
Guru Kashi University runs its own application management system, built in-house, and an internal CRM. The LMS is a separate system. Filari connected them through APIs, so a student admitted in one appears in the other, in the right courses, on their own.
01 · Admitted
The student is admitted
Admission is confirmed in GKU's own application management system, where it always has been.
02 · Created
The LMS account appears
The API creates the student's LMS account and adds them to the cohort for their programme, semester and section.
03 · Learning
Courses are waiting
On first login the student already sees their courses. No spreadsheets, no manual uploads, no duplicate records.
Online exams for the whole campus, on servers we run for you
Filari built Guru Kashi University's online examination system on the same LMS, and manages the whole platform on AWS: hosting, security, updates and cost. The hardest week is exam week, when thousands of students log in at the same minute.
The online examination system
- Question banks per courseFaculty build banks by unit and difficulty, reused each semester.
- Scheduled exam windowsEach faculty's exam timetable opens and closes papers automatically.
- Timed, randomised papersEvery student gets a shuffled paper with the same difficulty.
- Auto and manual markingObjective answers are marked at once; written answers go to faculty.
- Results to the gradebookMarks land in one place, ready for result processing.
How the servers follow the semester
Illustration · shape only, no real data
Extra servers are added before each exam window and load-tested for the expected number of students at once.
Servers are right-sized for normal weeks, scaled down after exams, and old files move to cheaper storage.
Encrypted connections, regular patching, restricted admin access and monitoring, closest during exams.
Moodle and plugin updates are tested on a staging copy first, then rolled out outside exam periods.
Regular backups of the database and course files, with a tested way to restore them.
Filari maintains the LMS end to end, so the university has one partner for the platform, the exams and the servers.
One LMS the whole campus can find its way around
Guru Kashi University runs e-learning and online exams for every faculty on one Moodle site that Filari operates and connects to its own admissions system and CRM. Each course has a place and an owner, each batch is enrolled in one step, deans can see how their faculty is using the LMS, and exam weeks run on capacity added for them.
Courses sit in their faculty, programme and semester, with a named owner.
Admitted students reach their courses through cohorts filled from admissions.
LMS activity is reported by faculty and programme.
Servers are raised for each exam window and lowered after.
Three decisions that keep a 13-faculty LMS in order
One Moodle site with a branch for each faculty
A separate LMS for each faculty
Students and teachers keep one login and one look, coordinators manage only their own branch, and deans get reports from a single source.
Cohorts filled by API from the admissions system
Enrolling each batch course by course
With 200+ programmes, manual enrolment does not scale. Admitted students are added to their cohort, and the cohort is synced to every course in one step.
Capacity raised for each exam window, then lowered
Servers sized for exam week all year
Thousands of students log in at the same minute during exams. Scaling around the window keeps exams stable without paying for peak capacity all semester.
What we learned
For a multi-faculty university, an LMS fails through disorder before it fails through missing features. Mapping the university's own structure into Moodle first, then giving each level an owner and a report, did more for adoption than any plugin. The second lesson is that exam week sets the hosting plan, not the average week.
For tech teamsUnder the hood
How Moodle is set up for a multi-faculty campus
Structure
Nested course categories: university → faculty → programme → semester
Permissions
Category-level manager roles for faculty coordinators
Enrolment
Site cohorts filled via API from GKU's application management system; cohort sync to courses
Courses
Template course restored for each new course
Reporting
Custom reports filtered by category
Access
One login per student and teacher
Questions about Moodle for multi-faculty universities
Yes. For Guru Kashi University, Filari built an API layer between the university's in-house application management system, its internal CRM and the Moodle LMS. Admitted students get an LMS account and the right cohort automatically, and status flows back without manual uploads.
Before each exam window, Filari adds server capacity on AWS and load-tests it for the expected number of students at the same time. The capacity is held through the window and reduced afterwards, so exams stay responsive without paying for peak servers all semester.
Filari manages Guru Kashi University's LMS end to end on AWS: hosting, security patching, monitoring, backups, Moodle updates tested on staging first, and cost control. The university has one partner for the platform, the exams and the servers.
Yes. Moodle organises courses into categories and sub-categories, so each faculty, department and programme gets its own branch. Guru Kashi University's 13 faculties share one LMS, while each faculty's staff manage only their own branch.
Moodle roles can be assigned at category level. A faculty coordinator gets management rights over their own faculty's category only, so they can create and staff courses there without touching anyone else's.
Students are grouped into cohorts by programme, semester and section. Each course is linked to the right cohorts, so a new batch is enrolled into all its courses in one step rather than one student at a time.
Leaders can see course activity, completion, assignment submissions and grades by faculty, programme or course. These reports help deans spot inactive courses early and give quality teams evidence of e-learning use.
No. At a campus university the LMS supports classroom teaching: faculty share material, collect assignments and run quizzes online, while lectures and labs continue on campus. Students keep everything for a course in one place.
If any of those four problems sound familiar, let's talk.
Send us your LMS URL and your next exam date. We will tell you what to fix first: structure, exam-day capacity, integrations or cost.
More projects like this one
Mobile-First Moodle LMS for Online Degrees
A Moodle LMS rebuilt for the phone: lighter pages, bottom navigation, readable content, one-question quizzes and reminders that reach the learner.
Moodle LMS for UGC-Entitled Online Degrees
One four-quadrant course template, weekend live classes, proctored online exams and one gradebook for Vignan's online MBA, MCA, BBA and BCA.
Education
Next.js + Strapi Rebuild for an AI School
Course content moved out of the code into a CMS the team runs, rebuilt on Next.js 16, Strapi 5, MySQL 8 and S3 without touching the live site.