Communication settings, preferences and costs

Community settings

Under Admin → Communications → Settings, configure email sender identity, optional SMTP, SMS and WhatsApp providers, cascade order, the sponsored message line, the separate notice-email sponsor toggle, and ticket-confirmation channels. After saving, send a controlled test Campaign on each enabled channel; selecting a provider is not proof that its credentials, sender identity and webhooks work.

Ticket email is always attempted for registered and waitlisted buyers. Extra confirmation channels apply only to confirmed member buyers; guests and waitlisted buyers do not receive that extra fan-out.

An optional sponsored line or notice advertising setting only prepares the message surface. The Advertising placement, accepted campaign, active creative and serving conditions still control whether a real sponsor appears.

Member preferences

The web preference centre stores marketing choices per community for email, SMS, WhatsApp and push. They default on for a new relationship. In-app notifications do not currently have the same marketing opt-out.

Preference implementations are not yet universal across every older mobile and web send path. Owners should still use the Communications campaign, newsletter and automation tools—which apply the current filtering—and honour a direct opt-out request. A transactional classification can bypass marketing preferences for a necessary service message, but should not be used to disguise promotion.

Rates and message credits

Open Admin → Costs for the plan's effective per-message rates and message-credit wallet. Email, in-app and push may be free while SMS or WhatsApp carries a configured rate; the effective plan or community override is the source of truth.

Only sends executed through the inline cascade engine are currently wallet-preflighted and debited. Saved Campaigns, newsletters and automations neither block on nor debit the message-credit wallet, even when a paid rate is displayed. Cascade preflight conservatively estimates every selected paid channel for every resolved person; the actual debit counts only accepted attempts. Treat rates on queued paths as estimates until billing is unified.