For certain workflows, SMS is still the most reliable channel. A delivery driver's confirmation that a package has arrived. A reminder the day before an appointment. An authentication code for a sensitive action. An urgent alert that a system needs attention now, not when someone next checks their email. Text messages have a response rate that email can't match — and for specific business operations, that difference is the whole point. A platform that aims to cover real-world business operations needs SMS available alongside email without turning it into a multi-week integration project.
SMS delivery is built into the platform as a first-class action. The automation builder offers a send-SMS action alongside send-email, exposed the same way: pick a recipient, compose a message (optionally using the inline expression language for personalization), and the automation handles everything else. Integrating a new SMS flow typically takes a few minutes of configuration and a test run — not a sprint of engineering work.
On the delivery side, the engine is provider-agnostic. Multiple backends are available, and each tenant configures the one that fits their region, their cost profile, and their compliance requirements. The action in the automation builder is the same regardless of which backend the tenant has picked, so implementers don't have to relearn anything when a tenant moves between providers or runs different tenants on different backends. That abstraction also means the platform doesn't wedge a particular vendor into every customer's stack.
Phone number normalization happens automatically. Numbers stored on records in various formats — with or without country code, with spaces or dashes, in local notation — are normalized to the international format before being sent to the provider. That avoids a category of silent failures where a number that looks right to humans simply doesn't match the provider's expected input. Implementers don't have to sanitize phone numbers at every send-point; the engine handles it.
Variables work the same way they do in the email engine. The inline expression language is available inside SMS message bodies, so a template can reference properties of the triggering record, the current user, date math, or any other expression the platform supports. The typical appointment-reminder message — Hi {customer.firstName}, reminder: your appointment is tomorrow at {appointment.time} — is a single readable template, rendered per recipient at send time. Consistency with email and with other expression surfaces means there's one syntax to learn, not three.
Length and segmentation are handled automatically where the provider supports it. SMS has hard per-message limits, and long messages segment into multiple parts that are reassembled on the recipient's phone. The engine handles segmentation transparently and, where the provider returns per-segment cost data, surfaces it for reporting. You write the message you want to send; the platform does the arithmetic.
Error reporting is explicit. Failures — a bad number, a provider outage, a country the tenant hasn't authorized — land in the automation's run history with the provider's response attached, so an implementer investigating a failure has something to work with rather than a generic "message not sent." For tenants that send SMS at volume, error visibility is what keeps operational issues from becoming silent.
Cost awareness is a feature worth calling out. Where the provider returns cost data, the platform records it alongside the send, which means SMS usage is a reportable quantity in its own right. For tenants operating at meaningful volume, that's what keeps the monthly bill from being a surprise.
Phone-property integration is the small detail that makes SMS feel native rather than bolted on. A phone property on a record is directly usable as an SMS recipient in the automation action — one click, pick the property, done. No additional normalization, no custom expression. That same phone-property integration also powers click-to-SMS actions on the record UI, where appropriate.
The honest caveat is that SMS comes with compliance responsibilities that email doesn't, and those responsibilities vary by region. Consent, opt-out, time-of-day restrictions, and per-country rules are all considerations tenants need to be aware of. The platform supports the mechanics — honoring opt-out flags on records, rate limits, scheduled-window sends — but the regulatory posture is a business decision, not a technical one. We'll be direct about that: sending SMS at scale is a capability, not a license, and the implementer using it is responsible for its ethics and its compliance.
For the workflows where SMS is the right channel, though, having it built into the same automation surface as email is what makes multi-channel delivery a realistic option rather than a special project. The automation that sends an order confirmation by email also sends a delivery-day text message; the appointment reminder goes out by email 24 hours before and by SMS 2 hours before; the on-call alert pages a responder the moment a threshold is crossed. These are the patterns that the email-plus-SMS combination unlocks, and they belong where everything else happens: in the automation builder, beside every other action the platform offers.