Structured email studio
Communications editors share one structured design format, responsive compiler and version store. The owning product supplies audience, available variables, sending purpose and permissions. Saving a template is separate from sending it. Modules without an authorized audience/send workflow can remain template-only.
The studio includes subject, preview text, saved templates/version history, desktop/mobile preview and a block canvas. Blocks include headings, rich text, images, buttons, columns, quotes, dividers, spacers, social links and a footer. Allowed smart variables are product-specific; unsupported values cannot be used to access another product's data. Preview recipients and ticket examples are illustrative rather than real delivery evidence.
Saving uses the expected template version, preventing an old editor from silently overwriting new work. Archive hides a template without rewriting its previous versions. Sending freezes design and recipient variables into the owning delivery workflow.
Ticketing separates Series journey templates from one-off communications. Its confirmation design has a protected ticket/receipt delivery block; surrounding copy can be edited, but the block cannot be removed or duplicated. Booking journey content and SMS readiness remain in Bookings Communications.
Resend connection and sender settings
Email settings exist at Portfolio, organization and Series scope; Event
Communications previews its resolved connection and sender rather than holding
an Event-level API key. Organization entry is
/app/<orgSlug>/settings/communications/email, with a Series selector/subpage.
Portfolio entry is /portfolio/<groupSlug>/settings/email.
Connections resolve from Series to organization to Portfolio and then an allowed platform fallback. Sender identities resolve separately: a Series may inherit a connection while using its own verified sender. A configured but invalid child connection/sender blocks its route; failure does not silently change the brand. Only explicitly configured essential-transactional fallback can use a parent. Marketing has no implicit failure fallback.
Sender profiles distinguish transactional, operational, feedback and marketing purposes. The exact From domain must be verified with the resolved provider; Reply-To should be monitored. Provider delivery and marketing eligibility are independent controls.
A typical setup is to choose inheritance or a separate Resend account, give it a label and verified domain, save a key through the write-only credential field, configure sender profiles, send a test to the verified administrator and activate the exact tested revision. Settings expose masked fingerprint, test/health state, effective routes, fallback, recent changes and provider delivery-event setup. Secrets are not returned after save.
Rotation stages/test-validates a new key. Revocation previews affected scopes, frozen jobs and replacement routes. Revoked jobs stop instead of silently routing through another connection. A bounded/incomplete impact sample is labelled. Gmail connection and alias/signature controls coexist in organization Email settings but retain their separate account and Inbox privacy boundaries.
Delivery outcomes and SMS
Queued, provider-accepted, delivered, failed and uncertain are distinct outcomes. Retries use frozen content/source context and idempotency rather than sending a fresh lookalike message. Bounces, complaints and suppression can prevent delivery. A test send or saved template does not prove a complete customer journey.
Twilio provider readiness supports Bookings SMS content and signed status/incoming callbacks. The UI can save SMS templates while sending is unconfigured. Segment counts distinguish GSM-7/UCS-2 costs. Provider wiring alone is not a complete send workflow or a permitted audience; the owning product must freeze recipient, version, purpose, consent and suppression before sending.