Go-live and quiet mode

Every organization starts life in quiet mode (status: provisioning). While an org is in quiet mode, no member-facing email or SMS leaves the platform. Full stop. This is the safety floor that makes a real-data trial possible: staff can import the club's actual roster, run renewals, build workflows, and rehearse a full year without a single member hearing from the system.

Every member-facing email and text goes through one logged send layer, and that layer checks the org's status before anything reaches the email or SMS provider. Only the literal status live allows a send; provisioning, a missing org record, or any unknown status all block. The check is fail-closed. There is no configuration that lets a member message slip out of a quiet org.

Blocked sends are not silently dropped: each attempt is recorded in the message log with status blocked and the reason ("org status is not live"), so you can see exactly what would have gone out. On a household's timeline, and in campaign and workflow run detail. That visibility is the point of a quiet trial: rehearse the messaging, read what was rendered and blocked, and only then go live.

One exemption: staff sign-in messages (the magic-link email) still deliver while the org is quiet. Without that, the onboarding admin could never sign in to reach the go-live control.

Quiet mode gates outbound member messages, nothing else. Crons, workflows, Stripe webhooks, imports, and portal pages all keep running. Workflows will fire and their email steps will be logged as blocked, invoices can exist, data flows normally. Quiet mode is not a read-only mode; it is a "nobody gets messaged" mode.

Quiet mode and email confirmation are separate gates and they stack. After go-live, addresses that arrived through an import still receive nothing until each person confirms their address. Going live turns on messaging for the club, not for a list nobody has proved.

When the org is still provisioning, Settings shows a warning banner ("Provisioning: member email & SMS are suppressed") with a Go live button.

• Going live requires the admin role, and you must confirm. The confirmation warns that member email and SMS will start delivering for real.

• The flip is one-way from the UI. There is no "go quiet again" button; reverting after go-live is a manual operation by Swim Ops support. Treat the click as a launch decision, not a toggle.

• The flip is audited (an org.go_live entry records who and when).

• Clicking it on an already-live org is harmless. It changes nothing.

Before going live, review recent blocked sends (they show on household timelines and in workflow run history): anything a still-enabled workflow or armed automation tried to send yesterday will send for real tomorrow.

Quiet mode is how a club evaluates the platform on its own data without contacting its members. The shape of a trial:

1. The club's real roster is imported into a fresh, quiet org (see CSV member import for the staging, quarantine, and batch-report flow).

2. Staff work the real screens, renewals, waitlist, reports, campaigns, against real households.

3. Every member-facing message the rehearsal would have produced is rendered and logged as blocked, never delivered.

4. If the club adopts the platform, an admin goes live and messaging turns on from that moment forward. Nothing historical is re-sent.

Quiet mode gates messages, not payments. There is no product gate that blocks a charge just because an org isn't live yet.

In practice a trial org cannot move real money because Swim Ops support configures it against Stripe's test mode. An environmental safeguard, configured by Swim Ops support, not a structural rule tied to the org's status. Don't rely on "the org isn't live" alone as the thing standing between a rehearsal and a real charge; if you're unsure how a trial org's payment environment is configured, ask Swim Ops support before exercising checkout flows.