An email-to-SMS fallback for a customer support SaaS should begin with an escalation policy, not a second send call. The policy must say what counts as a bounce, how much delay the support workflow accepts, and who may receive the alert. The report template stays with the application because report meaning, redaction, localization, and approval history belong there.
Short answer: keep the generated report and notification state application-owned, treat polled email events as evidence, and send an SMS only after a confirmed permanent failure passes consent, suppression, and regional checks.
How should an email deliverability fallback strategy trigger an SMS alert?
For US and EU deployments, check consent, destination country, suppression status, message class, data sensitivity, and the deadline immediately before escalation. Record the policy decision and the notification version used to make it. A phone number in a customer profile is not, by itself, permission to send a fallback alert.
Keep the text narrow. “A support report needs attention in your account” points the recipient to an authenticated product surface without copying customer case content into a channel with a different privacy and retention profile. The report attachment remains in the email path and account system.
US and EU are useful deployment labels, not a complete compliance analysis. Purpose, recipient population, consent collection, contractual role, retention, and local messaging rules still matter. The responsible policy owner should validate those details for the actual product and deployment; geography alone cannot make the decision.
The escalation contract should distinguish four states: delivered, permanent failure, temporary failure, and observation failure. A missing event is not a bounce. A timeout proves that observation failed; it does not prove that the email failed.
The catch is latency. This design is not suitable when a login code, safety notice, or outage alert needs an alternate channel within seconds. Stick with push-based events or a purpose-built notification workflow when the objective is near-immediate escalation. Your mileage may vary with event latency, traffic shape, carrier filtering, and the support team's service-level objective.
What makes Node.js event polling reliable after a worker restart?
Treat polling as an observation loop, not as a delivery guarantee. A poll fetches a bounded batch of events, normalizes the source-specific shape, and joins each event to an open notification by message ID. The worker should advance only on a classified event. It should not infer a permanent failure from an empty response, a timeout, or an event that belongs to another message.
The critical path below uses generic interfaces so the policy stays independent of a particular provider. The surrounding Node.js service can schedule the function, while the persistence adapter stores the cursor, lease, and notification state.
from dataclasses import dataclass
from enum import Enum
from typing import Protocol
class Outcome(Enum):
DELIVERED = "delivered"
PERMANENT_FAILURE = "permanent_failure"
TEMPORARY_FAILURE = "temporary_failure"
@dataclass(frozen=True)
class Event:
event_id: str
message_id: str
outcome: Outcome
@dataclass
class Notification:
notification_id: str
email_message_id: str
phone: str
sms_allowed: bool
state: str = "pending"
class EmailEvents(Protocol):
def list_events(
self, cursor: str | None
) -> tuple[list[Event], str | None]: ...
class SmsSender(Protocol):
def send(self, phone: str, text: str, idempotency_key: str) -> None: ...
def poll_once(
items: list[Notification], events: EmailEvents, sms: SmsSender
) -> None:
observed, _next_cursor = events.list_events(cursor=None)
by_message = {event.message_id: event for event in observed}
for item in items:
if item.state != "pending":
continue
event = by_message.get(item.email_message_id)
if event is None or event.outcome is Outcome.TEMPORARY_FAILURE:
continue
if event.outcome is Outcome.DELIVERED:
item.state = "delivered"
continue
if item.sms_allowed:
sms.send(
item.phone,
"A support report needs attention in your account.",
f"report-fallback:{item.notification_id}",
)
item.state = "failed"
Polling details deserve more respect than they usually get. Persist the cursor with a polling lease, or use an overlapping time window and deduplicate by event ID. Bound each batch. Add jitter. Honor the event source's backoff guidance. Record event age, observation delay, poll volume, retry count, and SMS escalation count. I am not sure a universal interval exists: a weekly support digest and a time-sensitive account notice have different contracts.
If the source exposes no webhook, the system can still be well behaved, but the product must accept the delay and define what happens when an event never becomes observable. I don't infer a bounce from silence. Expire an open notification only under an explicit operational policy.
No shortcut.
Which team should own a support report's template?
The application should persist the report ID, template version, recipient reference, email message ID, and notification ID before dispatch. An operator can then explain exactly which attachment was generated, even after the current template changes. A delivery component should know transport IDs and response normalization; it should not quietly become the source of truth for what a support report means.
| Template model | Good fit | Cost or risk |
|---|---|---|
| Application-owned | Report meaning, redaction, localization, and review belong to one product team | The team owns release and approval work |
| Delivery-service-owned | Many products genuinely share centrally governed copy and policy | Business wording depends on another control plane |
| Mixed ownership | A platform supplies transport while the product supplies report content | The handoff must define which version is authoritative |
Application ownership is the default here. A delivery-service template can be valid for centrally governed operational notices, where one platform owns the message contract. It is a poor fit for generated support reports: an attachment and its explanatory text can drift apart, and a later fallback may be impossible to reproduce.
Template ownership is the decision. Channel choice follows it.
What should release tests prove about a channel switch?
The database transaction is omitted from the sample deliberately. In production, save the fallback intent before a sender claims it, then use the notification ID as the idempotency boundary. A process can stop between a remote SMS send and a local state write. A durable outbox and an idempotent sender make that window explainable and recoverable. For example, if a worker has observed a permanent bounce, written the fallback intent, and then exits before marking the notification as claimed, the next worker should claim that same intent rather than create a second one. If the sender has already accepted the idempotency key, a retry should resolve to the existing send; if it has not, the retry should be the first attempt. The exact transaction and sender contract depend on the persistence and messaging components, but the ownership rule does not: the notification ID must remain stable across the recovery path.
Test the state transitions: delivered, permanent failure, temporary failure, no event, duplicate event, stale event, worker restart, consent revoked, and an SMS sender timeout. Run the same failed notification twice. The expected result is at most one fallback alert, with a stable idempotency key and an audit record that explains the decision.
Then test the report itself. Pin a template version and fixture data, generate the attachment, and assert that the rendered explanation references that version. Change the current template after generation and confirm that a retry does not silently rewrite the already-created report. Test redaction independently from transport so a delivery retry cannot accidentally broaden the payload.
The rejected option is sending email and SMS at the same time. It removes polling delay, but it also sends an intrusive message for every successful email and duplicates context across channels. That option is valid for a deliberate broadcast with separate consent and separately reviewed copy; it is not a sensible default for bounce-driven escalation.
The final rule is narrow: own business content and state in the application, treat email events as observations, poll only within the workflow's latency budget, and escalate to SMS after a classified permanent failure passes policy. The architecture stays understandable because each decision has one owner and one recorded reason.
Top comments (0)