The monthly schedule was built by hand before the 15th.
Courses, groups and subgroups already lived in the CRM as smart processes, but next month's schedule was still assembled by hand, from memory and on paper: too many rules to hold at once. Clashes only surfaced in the classroom — and people, not the system, had to fix them.
We wrote a custom "Group schedule" module on top of the boxed CRM: three dedicated tables and zero changes to the core, so CRM updates leave it intact. The "Generate" button lays out next month's groups from each course's settings as an editable draft; the coordinator drags a group tile to another day and the schedule recalculates immediately, with clashes highlighted in red before anything is approved.
The rules that used to live in the coordinator's head — eight-hour days, long and short groups alternating, two groups of one course never in the same hours — are now set per course in the module. Access is split across inspector, coordinator and administrator roles, the schedule prints for any period with filters, and clicking a group opens its CRM record. A working version reached the client's server in two weeks: about 6,500 lines of code and 73 unit tests.
What was in the way
- ✗Next month's schedule was assembled by hand before the 15th
- ✗The rules — eight-hour days, long and short groups alternating — lived in the coordinator's head
- ✗Two groups of the same course could not share the same hours
- ✗Group numbering restarts every year
- ✗Clashes only surfaced once students had arrived
What the system does
Group calendar
A grid of working days with group tiles: course, type, number, student count. Groups continuing from last month carry their own marker; clashes are highlighted in red.
A draft in one click
The “Generate” button lays out next month's groups from each course's settings — not real groups yet, but a draft that can be edited.
Drag-and-drop edits
Drag a group tile to another day — the schedule recalculates immediately.
Print and navigation
Print the schedule for any period with filters applied; clicking a group opens its CRM record in a side panel.
Settings and roles
Each course defines its number of long and short groups and whether it joins auto-generation; access is split across three roles — inspector, coordinator, administrator.
How it fits together
The engineering behind it.
Zero core changes
The module lives in an isolated directory and uses the platform's standard mechanisms: its own tables, controllers and the smart-process API.
The “wave” scheduler
Groups of a course run in waves: parallel ones share a time slot, sequential ones follow each other; a wave fills the eight-hour day and carries the remainder over.
Two-phase finalization
CRM records are created first, then a transaction updates the module's own tables — a failure midway cannot leave the schedule half-created.