Say it once, and it reaches the people it should

A coach or team captain can post an announcement to their team; it appears on the coach and player dashboards and fans out to each member's in-app inbox, web push, and email.

Editing, pinning and deleting an announcement are coach-only — a captain can post but not modify history (backend/src/handlers/teamFeedHandler.ts:1). Recipients must have a claimed user account; unclaimed roster entries are skipped.

Every team has a private chat that any team member — player, coach or captain — can post to, with read tracking, and non-members are refused.

Updates reach other devices by polling on a short interval plus a same-origin cross-tab channel (frontend/src/pages/app/TeamChatPage.tsx:8, :55), not a persistent WebSocket. Chat history is served as the most recent messages, not an unbounded archive. There are no attachments, reactions, edits or deletes — a message is plain text capped at 2000 characters, and no route exists to change or remove one once posted (backend/src/handlers/teamFeedHandler.ts:193).

Every user gets an in-app notification inbox with a bell in the top bar, a full notifications page, and mark-one / mark-all-read controls.

The bell is a client-side poll of GET /notifications (routes/index.ts:2096 documents it as the bell-icon poll), not a server-pushed stream. The list returns the user's most recent notifications, not unlimited history.

Users can opt in to browser and mobile web push from their profile settings; the platform registers the subscription, delivers notifications through the standard Web Push (VAPID) gateways, and prunes subscriptions the browser has revoked.

Requires the user to grant browser notification permission; Safari only supports it inside an installed PWA (frontend/src/services/pushClient.ts:1). Delivery is best-effort and never blocks the underlying action. Push is dormant on any environment whose VAPID keys are absent or still hold the PASTE_ placeholder — sendPush() no-ops, GET /push/vapid-public-key answers 204, and the SPA hides the enable control (backend/src/services/webPushService.ts:77).

Fans who follow a league receive match alerts — match going live, scoring plays, period end and final score — in their inbox and as web push, driven straight off the scoring write path.

Two opt-in layers apply: the per-league follow toggles (notifyOnLive / notifyOnFinal, both default on at first follow) and the user's global per-type preference. Email is sent for the FINAL milestone only — live, score-change and period-end beats are inbox and push only (backend/src/services/notificationService.ts:365).

Roughly a day before a scheduled match, every member of both teams is automatically reminded in-app, by web push and by email, on a scheduled job that runs continuously without an admin having to press anything.

Recipients are team members with claimed accounts, not league followers or ticket holders. Each match is reminded once, deduplicated. The sweep processes at most 200 matches per run (backend/src/services/pregameReminderService.ts:15) and honours the user's gameReminders toggle, so anyone who has switched that off receives nothing.

Each user has a server-stored preference matrix — grouped into live-match, league news, system and officiating toggles — and the delivery paths check it before sending.

Toggles are per notification TYPE, not per channel: there is no separate email-vs-SMS-vs-push control and no quiet hours / do-not-disturb, both deliberately omitted (frontend/src/pages/app/settings/NotificationSettingsPage.tsx:17). Per-league mutes ride the same SPA-owned prefs envelope as leagueMuted:<id> keys, but no send path reads those keys — the per-league opt-outs that actually take effect are the notifyOnLive / notifyOnFinal toggles on a league follow.

Invitations, receipts, digests, reminders and billing notices are sent through a single transactional email service with a verified sender domain, per-message tagging, and failure handling that keeps a dead mailer from destroying the surrounding action.

All mail leaves from one sender address (noreply@balloball.com); a tenant's own display name in the From line is available only to tenants entitled to white-label branding (backend/src/services/sesService.ts:47, backend/src/services/tenantEmailBrandService.ts:46). There is no per-tenant sending domain and no retry queue — a recipient-level rejection is logged and reported back as not sent.

A league admin can compose one message to a chosen audience — everyone, admins, followers, or a specific team — pick email and in-app channels, preview the recipient count before sending, and see per-campaign sent / skipped / failed counts afterwards.

League-admin (or platform-root) only, and gated on the league's NOTIFICATIONS feature module, which 403s the whole surface when switched off (backend/src/handlers/messagingHandler.ts:129). The SMS channel is DORMANT in production — the Twilio secret still holds placeholder values, so an admin can pick SMS but every SMS recipient is recorded as skipped with reason not-configured rather than texted (backend/src/services/smsService.ts:29).

Campaigns can be parked for a future send time, and multi-step drip sequences can be built, started and cancelled; a scheduled job runs every five minutes and delivers whatever has come due.

Same league-admin plus NOTIFICATIONS-module gate as the campaign surface. Sequences are cohort-timed — every recipient receives step N at the same wall-clock moment, not relative to their own signup — and the template and its steps can only be edited while the sequence is DRAFT; once started, edits are refused with a 409 until it is cancelled back to DRAFT (backend/src/handlers/commsSequenceHandler.ts:18).

Each campaign records a per-recipient delivery outcome — sent, skipped or failed, with a reason — and the admin drill-down shows those rows with the email address or phone number masked so raw member contact details never leave the backend.

The log records the outcome of the send attempt only; it does not track opens, clicks, bounces or unsubscribes.

A league admin can preview a composed weekly digest — standings leaders, top performers, recent results and upcoming fixtures — and send it by email to opted-in admins and followers.

MANUALLY TRIGGERED. There is no scheduled job that sends it automatically; an admin must open the league and press send (backend/src/handlers/leagueHandler.ts:2951, and the only comms cron — backend/src/handlers/commsTick.ts — runs campaigns, pre-game reminders and the recycle-bin purge, never the digest).

Teams can be given a structured logistics-only channel with pinned posts and read tracking, plus an admin-readable, CSV-exportable audit log of team communications.

OFF BY DEFAULT — the MODULE_TEAM_COMMS_V2 feature module ships disabled and must be turned on per league before any of these endpoints answer (infrastructure/lambdas/db-init/platform-features.sql:3864, backend/src/handlers/teamCommsV2Handler.ts:226). The audit log only starts mirroring messages once the module is on, so anything posted before that is never captured, and it is readable by league admins or platform root only (backend/src/services/teamCommsAuditService.ts:36).

Guardians can be linked to a minor player, and messages that breach the guardian-visibility policy are detected on the chat write path and recorded for an administrator to review and resolve.

IT LOGS, IT DOES NOT BLOCK. The service explicitly does not prevent the message from being sent in this version (backend/src/services/guardianMessagingService.ts:18), and no notification is sent to the guardian when a violation fires. Do not describe this as enforcement: policyAllowsMessage always returns allowed:true today, so the message is persisted and delivered either way and an administrator reviews the violation afterwards.

Sign-up verification and password-reset email is generated by the platform's own sender rather than the identity provider's default mailer, so the content and branding are under platform control.

Delivery depends on the mail provider's API key being present in the environment's secret store; if it is missing the auth Lambda fails loudly rather than silently dropping the message.

The scheduled communications job isolates each of its sweeps so one failing campaign cannot suppress game-day reminders, and any run that fails outright lands on a dead-letter queue with an alarm attached rather than disappearing.

This is operational plumbing, not a customer-facing uptime commitment. No delivery SLA, retry-until-delivered guarantee, or per-message tracing is offered.