Emails API

The Emails module owns template authoring, reusable email components, WordPress email mappings, preview/test-send helpers, and email transport. The shared Automations platform now owns event-based automation workflows, including email-send actions.

Module Scope

Owned by Emails: templates, components, rendering, preview, WordPress email overrides, queue processing, and email transport logs
Owned by Automations: workflow storage, workflow actions, trigger matching, provider actions, outbound webhooks, and migrated email automation definitions

Core Services Still Owned by Emails

EmailTemplateService — template CRUD, settings, and designer document ownership
EmailComponentService — reusable email component CRUD
EmailRendererService — renders HTML and text versions from template data plus runtime context
EmailDispatchService — dispatches final email sends and bridges email-send workflow actions into transport
EmailScheduleService — schedules email reminder and delayed jobs for the transport queue
EmailQueueService — email transport queue ownership, claiming, send success, failure, retry, and deletion
EmailPreviewService — sample preview context and test-send behavior
WordPressEmailBridge — rewrites WordPress core emails through `wp_mail()`-time integration

How Automations Use the Emails Module

The shared Automations platform stores email workflows in the shared automation tables. When a workflow action uses action_key = email_send, the workflow runtime resolves the action and hands the actual email delivery work off to the Emails module services.

That means email sends still use the existing template, renderer, preview, schedule, and queue infrastructure, but the decision when to send the email is no longer owned by the Emails admin page.

In the current builder UI, the email_send action is configured from the shared visual workflow builder as a first-party BRM action. It intentionally does not require an external automation connection. Delays and step conditions are now owned by the shared automation action row that leads into that email_send action, while actual delivery still hands off to the Emails services once the runtime reaches that step.

Normal email-action setup is also guided. The shared builder sidebar exposes template and recipient-related selectors, uses tooltip-based help for compact explanations, and keeps raw config JSON out of the normal setup path for routine email workflows.

The Emails screen itself also remains the owner of starter-template creation and designer editing behavior. Template creation still enters through brm_email_create_from_starter, and the current starter registry now includes a first-party New Content Available message template for release and unlock announcements. Inside the designer, inline canvas editing now covers not just plain text blocks but also button labels, quote content, list items, table cells, and social-link labels while syncing those edits back to the normal inspector-backed document settings.

Gift Account and Claim Emails

The newer gifting flows do not create a second email platform. They reuse the existing boundaries in two different ways:

When BRM creates a recipient account automatically, WordPress sends the standard new-user email. That means the Emails module can still brand or remap that experience through its WordPress email ownership.
Native gift claim emails are sent from the gifting runtime through EmailTransportService. The gifting module owns the business decision to send them, but transport still uses the normal email transport boundary.

Do not move native gift claim-email business logic into the shared Automations platform unless the runtime ownership changes. Today, the gifting module owns claim lifecycle decisions, and Emails owns transport.

Admin Surface

BricksMembers → Emails keeps Templates, Components, WordPress Emails, Queue & Logs, and Settings
A conditional Upgrade Issue tab appears only when EmailAutomationMigrationService reports migration_failed
BricksMembers → Automations → Jobs is the shared workflow queue/log surface for provider and webhook actions

A healthy install does not keep a permanent Automations tab inside Emails anymore. New workflow creation and day-to-day workflow management belong to BricksMembers → Automations; the Emails page only exposes the conditional upgrade issue surface when legacy email automation migration needs manual attention.

AJAX Handlers Still Owned by Emails

These remain under src/Ajax/EmailActions.php and require manage_options plus the BRM admin nonce:

brm_email_save_settings
brm_email_save_wp_mappings
brm_email_save_template_settings
brm_email_save_designer_document
brm_email_update_template_title
brm_email_update_component_title
brm_email_render_preview
brm_email_send_test
brm_email_create_from_starter
brm_email_delete_template
brm_email_delete_component
brm_email_create_component_from_blocks
brm_email_get_component_document
brm_email_get_job_detail
brm_email_delete_job
brm_email_plan_reminders_now
brm_email_process_queue_now
brm_email_retry_failures_now

Storage Model

brm_email_template and brm_email_component post types remain unchanged
brm_email_jobs remains the email transport queue
Legacy rows from brm_email_automations are migrated into the shared automation workflow/action tables
The migration and cleanup state is tracked in brm_email_automation_migration_state

Runtime Contract

For event-driven emails, the active runtime path is now:

The shared automation runtime matches an event to a workflow
The workflow runtime reaches an email_send action
The Emails module renders and dispatches the email using the existing email services
Queue-based email delivery continues through the existing email queue services

WordPress core email mappings still bypass the shared workflow queue. They remain inline `wp_mail()` rewrites through WordPressEmailBridge.

Cross-Reference

Shared automation architecture: docs/dev-posts/30-automations-platform-api.html
Emails admin reference: docs/ui/emails-admin.md
Automations admin reference: docs/ui/automations-admin.md