F
Fand_igor

Internal Management Analytics Dashboard for University

I developed an internal modular dashboard for university management analytics. The project consolidated several data circuits and provided management and staff with a unified portal featuring indicators for the admissions campaign, students, finances, faculty, and personnel structure. The system was built as a discrete web application on CodeIgniter 4 with role-based access, a custom user model, caching, a template-based modular architecture, and integration with several 1C APIs.

The key idea of the project was to move away from working with fragmented exports and service reports individually and gather them into a single point of decision-making. As a result, different roles gained access only to their specific analytics circuits, and the data itself was loaded from 1C, normalized, cached, and laid out across specialized screens and widgets.

Project Context

  • Designed as an internal portal for employees and managers.
  • Used for management control across several university activity areas.
  • Consolidated data from different 1C circuits, rather than a single database.
  • Provided the ability not only to view summary indicators but also to drill down into the data structure by departments, directions, levels of training, forms of study, and personnel composition.
  • Built as an expandable modular system where new specialized dashboards could be added without a complete application overhaul.

What has been implemented

  • Implemented a unified internal portal with authorization, sessions, cookies, and role-based access differentiation.
  • Built a modular architecture where each analytical circuit was connected as an independent module with its own routes, menus, controllers, libraries, views, and client scripts.
  • Assembled the main dashboard circuit and separate modules for the admissions campaign, students, finances, faculty, and staff.
  • Implemented dynamic module registration and automatic connection of routes and menu items through the project file structure.
  • Created a common template layer for pages, assets, JSON data, client scripts, and widgets.
  • Implemented a service layer for integration with several 1C APIs.
  • Configured data retrieval from different 1C sources for different business areas: prof for academic and admissions data, bgu for the financial circuit, kdr for personnel and organizational structure.
  • Added caching for 1C responses and reuse of already loaded data to avoid overloading external services and speed up dashboard opening.
  • Implemented a more secure caching scenario with verification of suspiciously short or incomplete responses to avoid overwriting correct data with invalid exports.
  • Added the ability to force data updates and service mechanisms for reloading.

Analytical Circuits of the Project

Admissions Campaign

  • Implemented a separate module for admissions campaign analytics.
  • Supported data import from 1C via JSON with service identifier and secret verification.
  • Saved obtained exports in an import history and separately logged parsing errors.
  • Implemented loading and updating of plans, structures, directions, groups, and registries for the admissions campaign.
  • Built widgets for number of applicants, levels of training, forms of study, admission grounds, dynamics, and structures.
  • Created analytical tables by departments, directions, competitive groups, and application geography.
  • Added a settings screen where parameters could be pulled from 1C, local settings stored, and registry/group mapping corrected.
  • Implemented a local settings layer for levels, forms of study, budgets, submission methods, and additional admissions campaign parameters.

Students

  • Implemented a student dashboard with a set of widgets and detailed reports.
  • Displayed indicators for total number of students, international students, target-funded education, academic leaves, transfers, expulsions, reinstatements, and graduates.
  • Added breakdowns by months, training levels, faculties, courses, specialties, and citizenship.
  • Implemented geographic representations by Russian regions and countries.
  • Created separate tables and visualizations for detail on specific report types.

Finances

  • Implemented a finance module with separate role-based access.
  • Displayed consolidated financial reporting based on 1C data.
  • Built breakdowns by directions, KFO, and analytics articles.
  • Implemented detailed tables for income and expenses.
  • Added a payment and debt control circuit for students with breakdowns by departments, courses, and categories.

Faculty and Structure

  • Implemented a separate module for structure and faculty.
  • Built navigation by organizational structure with transition from the top level to specific departments and chairs.
  • Added safe routes based on numeric identifiers to avoid dependency on unstable or inconvenient string identifiers in URLs.
  • Implemented collection and caching of department structures, employees, and personnel parameters as of a selected date.
  • Built widgets for headcount, department structure, academic degrees, academic parameters, and vacant positions.
  • Supported different display scenarios for departments with and without faculty.
  • Implemented detail for a specific sub-department and a separate screen for a department.

Employees and Dual Appointments

  • Implemented a separate module for employees and dual appointments.
  • Collected a tree structure of the institute and departments based on personnel circuit data.
  • Formed a list of employees for each level of the structure.
  • Showed additional dual appointments and other positions of the same employee as expanded information.
  • Provided the ability to see not only an employee's department affiliation but also their other roles, employment, and FTE volume.

Technical Highlights

  • Architecture was built as a modular platform where each dashboard represented a separate functional block with its own server and client parts.
  • Template layer automatically gathered module assets, combined them into a common frontend package, and connected only the necessary interface parts.
  • Menu was formed dynamically based on module configuration and role checks.
  • Role model was built through user and group tables with access checks at the route and interface point level.
  • For 1C integration, a separate API layer was implemented that encapsulated request building, external method calls, response decoding, and caching.
  • For some requests, used not only a standard TTL cache but also a response metadata verification mechanism to avoid accepting incomplete or suspiciously short responses as correct updates.
  • In the admissions campaign circuit, data was not only read from 1C but also imported into a local DB with its own normalization, registry transformation, and accumulation of internal structure.
  • In the faculty module, implemented separate logic for restoring structure as of a date, data aggregation by departments, and building historical personnel snapshots.
  • At the interface level, used separate client modules and library plugins for tables, charts, filters, dates, and interactive navigation.

What the project demonstrates

  • Ability to design not just one screen, but an internal management analytics system with several subject circuits.
  • Experience integrating with multiple 1C sources within a single application.
  • Ability to build a modular architecture where the system can be expanded with new sections without a complete core overhaul.
  • Experience developing role-based portals for internal users.
  • Ability to translate heterogeneous data into clear analytical screens, tables, charts, and management views.
  • Experience designing a middle layer between external APIs and the interface with caching, normalization, and protection against poor-quality responses.
  • Experience working with analytics for admissions, students, finances, organizational structure, and personnel data in one project.

Technologies

  • PHP
  • CodeIgniter 4
  • JavaScript
  • jQuery
  • ApexCharts
  • DataTables
  • Select2
  • Air Datepicker
  • Less
  • Gulp
  • MySQL
  • 1C API Integration

My role

My role included developing the internal web application, designing the modular architecture, building role-based access, integrating with multiple 1C circuits, implementing caching and data loading logic, developing analytical modules for admissions, students, finances, faculty, and staff, and configuring the client part with widgets, tables, and charts.

Practical value of the project

This case effectively demonstrates working not with a single local task, but with a systemic management tool:

  • consolidation of several analytical directions in one portal;
  • integration with multiple 1C circuits;
  • development of modular architecture and role-based access;
  • building analytics for different roles and departments;
  • combination of local storage, import, normalization, caching, and visualization;
  • work with real management and operational scenarios of a university.