A district decides to do something once, centrally, instead of leaving fifty schools to reinvent it separately. That is usually the right call. A single attendance-notice rule, written by the district office, is more consistent and easier to audit than fifty versions built by fifty administrators with fifty different ideas about wording and thresholds. But the moment a district authors something once, a second and third question show up right behind it. Does a school still see this as its own, in its own numbers? Does standardizing the rule also mean standardizing parts of it that were never the district’s to touch?
At the scale of a single school, “can we send it” is close to the whole question. At district scale, that question gets replaced by three narrower ones: who authors, who measures, and who decides. Three recent changes to Bloomz answer one of those questions each, and they are more useful looked at together than apart.
Who authors: a district-written notice, in the school’s own Oversight
Auto notices, the automated messages a school sends when a rule fires, such as an attendance notice when a student is marked absent, used to have an odd gap once a district got involved. A district could write an attendance-notice rule and roll it out to every school so nobody had to rebuild it fifty times. But if a school administrator opened Oversight and filtered to Auto Notices, they saw none of the district’s notices. The feed only matched a notice to the context it was authored in, so a notice written at district level simply never appeared at school level, even though it was firing on that school’s own students every day.
That gap is closed. District-authored auto notices now appear in a school’s Oversight alongside the school’s own, so an administrator gets the full picture of what is going out to their families, not just the subset they personally wrote. It does not show up as one district-wide statistic dropped into the school’s feed, either. The Sent, Received, and Read counts on a district notice are recomputed to that school’s own families, not the district total, so a principal sees how the notice performed for their families specifically. A district administrator’s own view is unchanged; they still see the district total. Nobody loses visibility. Each administrator sees the number that is actually theirs.
This is what makes central authoring worth doing. Writing a rule once only saves work if the school still gets an honest account of what happened at their own door. A count that only ever reads the district total is not accountability, it is someone else’s number with the school’s name attached.
Who measures the deadline
A sign-up, a conference slot, a volunteer shift, a classroom help request, is only as reliable as the cutoff behind it. Families need to know that once a deadline passes, the roster is final and nobody can jump in late or bump someone who signed up on time. Bloomz has always supported a cutoff on a sign-up. What was clumsy was setting one: the deadline could only be added after the sign-up already existed, which meant creating it, saving it, and reopening it to add the cutoff as a second step. Parent-teacher conference sign-ups had no cutoff option at all.
Now the deadline is part of creation. It is chosen as a relative measure (six hours, one day, two days, or one week before the event starts) or as a specific date and time, and it is clamped so it can never land after the event has already begun. Conference sign-ups, covered in more depth in parent-teacher conference scheduling for districts, get the same option every other sign-up type already had.
The measurement is not just a courtesy in the interface. The same rule is enforced on the server, so the cutoff holds no matter how the sign-up was created. A deadline that only holds when the front end remembers to check it is not really a deadline. One enforced where families actually submit is. More on why that server-side hold matters in sign-up deadlines that hold.
Who decides what language a family hears
Bloomz has always kept two settings apart: the content language, meaning what language a school’s messages and posts are delivered in, and the app language, meaning what language the interface itself speaks. They sound like the same thing and they are not, and conflating them is exactly the mistake that makes a “translated” platform still hard to use. See message translation vs full-app translation for the fuller version of that distinction.
The new piece is who is allowed to set the content language on a family’s behalf. A school or district can now turn on a toggle in Settings, under Bulk Import, General Permissions: “Let your student information system overwrite a user’s preferred language.” It sits beside a setting districts already know, the one that lets the SIS overwrite a guardian’s email and phone number. It is off by default. Turn it on and the nightly SIS sync becomes authoritative for a family’s content language, so whatever language is on record in the SIS is the language the school communicates in, useful for a district that wants one source of truth instead of an in-app preference quietly drifting out of sync with the front office.
What the toggle does not touch is the app language. That stays the family’s own choice, always, whether the toggle is on or off. When the lock is on, a family sees the content-language picker as read-only, with an explanation why, but can still set the interface to whatever language they read most comfortably. A district gets to decide what language its official communication goes out in. It does not get to decide what language sits on a parent’s own phone. We wrote the deeper version of this distinction, including why the two settings have to stay apart, in who decides your family’s language.
Why these have to be answered together
None of these three changes is dramatic on its own. A notice that shows up where it should. A deadline set earlier instead of later. A toggle that is off by default. Put next to each other, they describe the same discipline applied three times: centralizing something at district level is only as good as what it leaves alone.
Authoring a rule once is only useful if the accounting that comes back from it is still local. A principal who cannot see their own numbers on a district-authored notice has gained a rule and lost visibility, not a trade a district should make on a school’s behalf. Standardizing a setting is only acceptable if the personal half stays personal. A district that can set a family’s content language should never be a district that can also reach into what language sits on a parent’s own home screen. And a rule is only a rule if it holds the same way no matter who set it up, the quiet promise behind moving a sign-up deadline into creation and enforcing it on the server rather than trusting whichever form happened to write it.
Districts do not choose a communication platform because it can send messages. Nearly any platform can do that. The harder test is whether it can do all of this at once: let the district move fast without asking every school to give up its own picture of what happened, and let a family keep the parts of their account that were never the district’s to touch. That is what actually decides whether a district-scale rollout holds up once fifty schools and thousands of families are using it every day, not just at the demo. It is the same instinct behind building a platform for teachers that scales to districts instead of the other way around.