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: it drafts the schedule in one click, and the coordinator only adjusts it by dragging and approves it.
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.