Announcements
One message to everyone, kept deliberately narrow
Practice is cancelled, the bus is late, the hall has moved. A message like that needs to reach a group at once and needs to stay a message — not become a thread with two hundred people replying to it. This is where the line is drawn, and one place it was drawn by choosing not to build something.
- 1
- row per announcement, whatever the audience
- 0
- replies an announcement can receive
- 1
- role that may send by default: the owner
- 0
- approval queues, on purpose
- Stored once with an audience rule, never per recipient
- Cannot be replied to — refused by the database, not hidden by a screen
- Who may send starts closed, at the organization owner alone
How it is stored
One row, not a hundred thousand
The storage shape is not an implementation detail here. It is what makes the rest of the behaviour possible.
One announcement is one record
It is written once, with a rule describing who it is for. It is never expanded into a copy per recipient, so a message to an organization of four thousand young people is one row, not four thousand.
The audience is derived as it is read
Who receives it is worked out from the organization's current structure at the moment somebody opens it — the same way oversight is. Somebody who joins the chapter after it was sent sees it; somebody who left does not.
Which is why it can be corrected
Removing an announcement removes one thing, and everybody who received it is told — because an announcement is the message most likely to be withdrawn for being wrong, and the people who acted on it are the ones who need to know.
Broadcast is kept narrow on purpose. Sending one message to a group is communication; scheduling, attendance and sign-up sheets are event management, and this product is not that.
Who it reaches, and who may send
Three audiences and a permission that starts closed
The default is the strictest one available, which is the direction a mistake should fail in.
- The whole organization
- Everybody, in every chapter. The blunt option, for the message that genuinely is for everybody.
- A chapter, and everything under it
- One province, one branch, one group — and its descendants. This is the one most announcements actually want, because most news is local.
- A role
- Leaders only, or young people only, or guardians only. A message to volunteers about a rota should not arrive on a fourteen-year-old's phone.
- And who may send it starts at one person
- By default only the organization owner. Widening it is a deliberate act by somebody with the authority to make it, recorded with their name — not a setting that shipped open and had to be closed.
- With a floor underneath
- An organization can narrow who may broadcast; it cannot widen past the platform's minimum role. “Nobody announces here” is a valid configuration. “Anybody does” is not.
Every announcement records who sent it, to which audience, and when — in the same transaction as the sending.
The step that is not here
There is no approval queue, and that was decided rather than skipped
A settings screen once offered “a supervisor reviews the message before it leaves. Strongly recommended.” No such workflow existed anywhere in the product. Rather than build it, we asked whether it should exist.
What is missing
Nothing holds an announcement for a second person to approve before it goes. A leader with permission to send sends, and it arrives.
Because nobody is available at 6am on a Saturday
That is the deciding argument, and it is not a shortcut. The bus is late and forty young people are standing in a car park. Either the message waits for a supervisor to wake up, or the person sending it gives up on the product and texts the children directly from their own phone — which is the exact behaviour this platform exists to prevent.
So the control is who, not when
Permission to broadcast is narrow and starts closed, every announcement names its sender, and any of them can be withdrawn with everybody who received it told. Oversight after the fact, on a channel nobody can leave, beats a gate people route around.
An approval queue that gets bypassed is worse than no approval queue, because it moves the conversation somewhere nobody can see. That is the whole reason this is a section rather than a silence.
One-way, by construction
An announcement cannot be replied to
Not discouraged and not hidden behind a missing button.
The database refuses it
A reply to an announcement is not a message the product declines to display — it is a row the database will not accept. A probe asserts it on every change, alongside the case that proves the assertion could fail.
Because the alternative is a group chat nobody chose
A broadcast that accepted replies would become a thread with the whole organization in it, where every young person can see every other young person's response. That is a different product with different safeguarding properties, and it would arrive by accident.
But it is still overseen
An announcement sits in the same record as everything else: readable by the leaders who oversee the young people in its audience, carried in the audit trail, and subject to the same curfew rules as any other message.
If somebody needs to respond to an announcement, they message a leader — in a conversation that is overseen, screened and recorded like every other one.
In short
What to tell your board
Three sentences, all of them checkable.
- An announcement is one record with an audience rule, so it can be corrected as one thing and everybody who received it is told.
- Permission to send starts at the organization owner alone and is bounded by a platform floor an organization cannot widen past.
- There is deliberately no approval step, because a gate nobody can staff at 6am on a Saturday is a gate people route around — and routing around this product means texting a child directly.