Email is still the default channel for transactional messages. Password resets, order confirmations, appointment reminders, invoice notifications, weekly digests, the small everyday signals that keep a business running — most of them happen by email, and most recipients expect to receive them there regardless of what other channels exist. A platform without a proper email engine forces implementers to stitch together provider SDKs, invent a templating system, manage deliverability, and maintain all of it over time. That's a lot of work for a universal need. Our email engine handles it natively.
On the sending side, the engine supports multiple provider integrations behind a uniform interface. Implementations aren't locked to a single delivery vendor; the tenant's operators choose a backend that matches their deliverability requirements and compliance profile, and the rest of the platform talks to email through the same action regardless of what's underneath. That abstraction matters practically — it's the difference between a tenant whose email can follow their broader infrastructure choices and one that's stuck with whatever the platform picked on day one.
Each tenant mails from their own from-address and from-name, with the appropriate domain configuration. A password reset email from a tenant's application comes from the tenant's own identity, not from a generic platform address. That's table stakes for perceived professionalism and for deliverability: mail that arrives from the sender the recipient expects is the mail that actually lands in their inbox. System emails — those triggered by the platform itself rather than by tenant automation — also send from the tenant's identity, so the distinction is invisible to end users.
Attachments come along naturally. A file property on a record can be attached directly to an outgoing message. A PDF generated by the platform (see the PDF-generation article) can be attached to the confirmation email that accompanies it. Explicit attachments from the file repository are also supported. That's what makes the common pattern — generate a PDF, attach it, send it — a one-step flow rather than three fragile steps.
BCC, CC, and Reply-to headers are first-class concerns, not afterthoughts. Reply-to in particular matters for business workflows: the acknowledgment email that accompanies a new support ticket should, in most setups, have a reply-to that lands responses back into the ticketing system. The send-email action in the automation builder exposes all of these fields, and expressions can drive any of them — so different emails from the same automation can route replies to different places, depending on context.
For sandboxed or staging environments, a mailer toggle shuts off outbound delivery without removing it from the implementation. A staging tenant continues to behave like the production tenant for testing purposes, but its automation runs don't actually send email to real recipients. That's the small but important safety net that prevents a dry run on staging from filling a customer's inbox with test messages.
The templating side of the engine lives in a dedicated Email Templates module. Templates are managed entities with their own UI: a title, a subject line, a body, configuration for from-address overrides when needed, and an active/inactive flag so templates can be retired without being deleted. When a template is retired, automations that used it still have their history intact and can be easily redirected to a replacement. The flag keeps old templates from polluting the template-picker while preserving the audit trail.
Templates carry variables powered by the inline expression language. The record that triggered the automation, the current user, the current date, properties of related records — all of them are available in template bodies through the same expression syntax used elsewhere. A welcome template for a new customer can include their first name, their account manager's name, their start date, and a personalized link; the template is one piece of content, and each rendered email is the result of evaluating that template against a specific record. That consistency across surfaces — expression language in forms, in views, in automations, in templates — is what makes the platform learnable. You don't have three flavors of templating to maintain; you have one.
Direct body override handles the ad-hoc cases. When a specific automation wants to send a message without a dedicated template — because the message is truly one-off, or because the content is being composed dynamically — the send-email action accepts a body directly. That keeps the template catalog focused on reusable content rather than single-use messages that would otherwise clutter it.
Per-tenant branding applies to templates naturally. Headers, footers, colors, and logos follow the tenant's configuration, which means the same base template — a layout, a signature block, a consistent footer — is available across templates without each one having to redefine them. That's what keeps templates in a growing catalog visually consistent without manual effort.
Template rendering is sandboxed. Variables are evaluated; arbitrary code isn't. That eliminates a category of security concern that plagues less-considered templating systems, and it means administrators can let non-developers compose templates without worrying about what a crafty expression might do.
Sending an email from an automation is, in practice, four inputs: the recipient (an expression or a fixed address), the template (or a direct body), any attachments, and the context the template should render against. The automation takes care of the rest. For teams whose daily work involves a lot of transactional messaging — confirmations, updates, acknowledgments, reminders — this is often the feature that makes the platform feel like it's genuinely doing the work, rather than asking implementers to integrate a separate mail service every time a new flow appears.