The plan card on top
The plan name, students and teachers included versus today's count, and the overage the platform will add to the invoice. Without opening the subscription.
All modules
Back office
Limits
Every workspace has limits: how many students, how many groups, how much room for files. This screen says where the school stands against each of them before a save refuses, using the same arithmetic the save checks.
Closest to the limit 78 %
Over the limit 0
Near the limit 0
Used Maximum
Students hard 154 200
Groups hard 22 40
Cloud storage hard 3,280 5,120
Messages soft 3,900 5,000
auto space limits · counted by the same code the write checks
Limits
What this module does
57
space limits in one catalogue
80 %
the point where a meter turns amber
2
modes: refuse the write, or record it
0
things this screen ever writes
A grid of limits with meters
Every limit is a tile: used, limit and a bar. Amber from 80 percent, rose above the limit, and where no limit was set it says “no limit”.
The history of overruns
A soft limit records instead of refusing, so going over stays as a row: which limit, from when to when and by how much. A hard one refuses on the spot and leaves no trace.
Figures about the workspace
Staff active in 7 and 30 days, students with an account, storage used, messages and lessons this month. They show which limit is coming up first.
The operator sets them, not the school
Limits are raised by the Cerium operator on the client screen; here they are read only. The screen answers “how much is left”, it does not negotiate the plan.
Who sees what
A module is a permission, and which records may be touched is settled on write, not in the menu.
| Role | Sees | Changes |
|---|---|---|
| Owner | Every limit of the school, the breach history and the subscription plan. | Nothing. The screen is for reading; maxima are set by the Cerium operator. |
| Methodologist | The same as the owner: this module comes by default. | Nothing, for the same reason. Nobody writes anything here. |
| Teacher | Nothing until the school grants the module; then the same as management. | Nothing. It is safe to grant, because the screen shows numbers only. |
| Student | Nothing. This is the school's capacity account, not a student's business. | Nothing. The module is neither given nor grantable to them. |
The details nobody asks about during a demo
The things that only surface in the third week of working with the module.
What this module does not do
- tables of its own - every number belongs to the module that creates and counts it
- a write of any kind: not a maximum, not a mode, not the closing of a period
- a counter of mail or text messages - the mail layer records no school against a message
- day-by-day usage - the history here is the periods spent over a limit
From the very functions the modules call just before a write, not from a second query rewritten here. That way “what counts” has a single definition: when an archived group stops entering the number, it stops in both places at once. The whole screen arrives through one endpoint, so the figure in the table and the figure on the tile have no way of drifting apart.
A hard limit refuses the write at the moment the number would pass the maximum. A soft one lets it through and leaves a trace: a period over the limit opens as a row in the history and closes when the number falls back under the maximum. The “Mode” column says which is which, and a second table on the same track lists every period - which limit, from when to when, and by how much.
Because that limit does not count the school but ONE parent record, and that is exactly what the write checks: events per enquiry, invoices per order, messages in a thread, exercises in a section. So the screen shows the largest count in a single record and says so plainly in the “Scope” column. A total of every event in the school would answer no question this limit asks.
No. This screen writes nothing at all: not a maximum, not a mode, not the closing of a period. Maxima are set by the Cerium operator on the client screen - and the operator sees exactly this view, counted by the same function and drawn by the same component. A conversation about raising a limit therefore runs over one set of numbers, not two screenshots.
A bar of figures: tiles (tightest, over, near, capped, breaches), a subscription row where the school has one, and four cards each about one thing - the eight fullest limits as bars, the state of all of them in one stacked bar with a legend, where the occupied space comes from, and the lessons and messages of this month. Colour is a state, not a module: rose over the limit, amber from 80 percent, mint below it.
Usually not: live records enter the number and archiving frees the room. “Usually”, because the rule belongs to the module rather than to this screen - Team tasks count the load, that is unfinished cards plus those finished within ninety days, while Messages count everything the school has ever written. Hence the “What counts” column beside every limit, with one sentence: what enters the number and what does not.
No, and saying so plainly beats standing an empty tile there. Text messages the product does not send at all. Mail it does send, but the mail layer records no school against a message, so a counter would first need a send log and will arrive together with it. Day-by-day usage is missing for the same kind of reason: nobody takes snapshots, and the history is the periods spent over a limit.
No. Here the plan simply stands next to the facts: what is included, how many students and teachers the school has today, what overage the current period produced and when it ends. The card, the invoices and the plan change live in Settings, in the Stripe portal, and the tile links there. This screen answers “how much is left”, and takes no money.
See Cerium from the inside.
14 days on your groups and instalments. No card, no strings.