Broadcasts

Case or broadcast?

This is the decision the legacy tool got wrong most often: a sixth of its archive was proactive notices opened as one case per recipient FI, which buried the real cases under copies and made "resolved" mean "sent". Decide before you create anything.

The tests, in order:

1. Is there a submitter waiting on an answer? Then it is a case.
2. Would you otherwise open the same case several times with different recipients? Then it is a broadcast.
3. Does it need a first-response clock and a resolution? Case. Does it need to reach people who never asked? Broadcast.

Edge cases:

• An incident is both. The outage is a case (with the party who reported it, or OPN as the owner); the alert to the affected institutions is a broadcast about that case, sent from the case's Actions. Replies from people at the case's entities land on the case; anyone else's opens a new case linked to the broadcast and related to the original.
• A question prompted by a broadcast ("does this affect our sandbox?") comes back as its own case, linked to the broadcast. Answer it there.
• A single institution's maintenance window is still a broadcast (audience: that institution and the integrators beneath it), not a case, unless they asked something.

Categories

production_update, service_disruption, service_restored, sandbox_update, product_update, planned_maintenance, general. A disruption and its restoration are two broadcasts; the second names the first.

Urgency and channels

• regular reaches each person by their everyday preference (email, SMS, both, or in-app only).
• emergency reaches each person by their emergency channel — SMS for most. Use it for disruptions and outage alerts, never for updates.

In-app is always on for the audience; the rail counts what each person hasn't opened. The Recipients tab shows who gets what and why, and a name can be unticked for one send.

Audience

All entities (admins), or selected entities, each with everything beneath it. Extra recipients — an on-call address or mobile that isn't a user — are typed on the broadcast and belong to it alone, and are enough by themselves: a notice to people who are users of no entity needs no entity chosen. From a case, an operator may reach the case's owner and involved entities plus extras; a wider audience needs an admin. An agent's create_broadcast follows the same rule and must name a case.

The production-update rhythm

Three broadcasts per release, each its own message: the announcement about five to seven days out (window, expected duration, what queues and settles afterwards, where to reply), "beginning soon" about an hour before, and "complete" when it is done. If the window moves, a new announcement supersedes; if it is cancelled, say so with the same audience.

SMS text

Defaults to the first paragraph of the body, plain, wrapped with the carrier prefix and footer. Keep it to one or two segments; the Preview tab shows the count and flags characters that halve the segment size.

Sending

Nothing sends before the Preview tab: the email as rendered, the SMS as it will go, the resolved recipient list. An agent drafts (create_broadcast, preview_broadcast); a person sends (send_broadcast is a person's tool). A junior operator's broadcast waits for review like a response. A broadcast cannot be recalled; a correction is a new broadcast.

send_broadcast takes an optional scheduled_send_at (up to 90 days ahead): the broadcast is then scheduled and leaves from the dispatch job, which runs every five minutes — so within five minutes after the time, never before. cancel_scheduled_broadcast before it leaves returns it to a draft with its time kept. A production update announced for a date is the shape this is for; if the date moves, cancel and schedule again.