Send styled email

This Workflow Companion action sends a styled HTML email through an SMTP server that you configure. You build the email from blocks (headings, text, images, buttons) on the action's configuration page and see it take shape as you edit. A group of blocks can be shown only when a condition holds.

For a quick plain-text message, use the Send email action instead.

Getting started

1. Add an SMTP server under Settings → Actions → Email.
2. Add the Send styled email action to a workflow and open its configuration.
3. Build the email: add blocks and wrap anything that should not always appear in a Condition block.
4. Fill in Test data, use Preview, then Send test to see the result in a real inbox.
5. Copy the Template data starter from the Variables section into the action's Template data field in the workflow, and replace each name with a workflow value.
6. Fill in the remaining action fields: at least one recipient and a Subject.

Configuration

Action parameters

Recipient fields accept multiple addresses separated by commas, and every field supports variables so you can build addresses and content dynamically from the workflow.

• To: Primary recipients. Visible to everyone who receives the email.
• CC: Carbon copy — secondary recipients. Also visible to everyone who receives the email.
• BCC: Blind carbon copy — recipients hidden from everyone else.
• Subject (required): The subject line of the email.
• Template data: A JSON object with the values the email uses — see Template data. Required as soon as the email uses any values; it can stay empty when the email uses none.
• From: Optionally override the sender. Accepts a bare address, or a name and address such as Support <support@example.com>. Leave blank to use the SMTP server's From email and From name. The address must be one your SMTP server is allowed to send from, otherwise the server may reject the message or the email may be marked as spam.
• SMTP server name: The name of a server from the app settings. Used only when the action configuration is set to Set in the workflow — see below.

At least one recipient must be provided across To, CC, or BCC. Addresses are de-duplicated across the three fields, ignoring capitalization: an address that appears in both To and CC receives one copy, in the field that lists it first. There is no Body field — the content of the email lives on the action's configuration page.

Email content

Open the action's configuration page to build the email. Click a block on the email to open its settings in the panel. Add a block with the + that appears between blocks or drag one out of the Blocks section. Every block carries a small toolbar to drag it somewhere else, duplicate it, or delete it.

The Styles section of the panel applies to the whole message.

Conditions

A Condition block shows the blocks inside it only when its expression is true. The expression is evaluated against the Template data at the moment the email is built, and when it comes out false the blocks inside are left out of the email.

SMTP server

The email is sent through one of the SMTP servers configured in the app settings (Settings → Actions → Email). The Action settings section of the configuration page offers three options:

• Use default: Always sends through your default server.
• A specific server: Always sends through the server you pick.
• Set in the workflow: Sends through the server named in the action's SMTP server name field. Because that field supports variables, different branches of one workflow can send through different servers.

Changes apply immediately

Saving the configuration page changes what the next run of a live workflow sends — you do not have to deactivate and reactivate the workflow. The same immediacy works the other way: deleting a content block, deleting an image from your files, or renaming an SMTP server affects running workflows straight away.

Template data

The email gets its values from the workflow through the Template data field, which holds a JSON object. Keys are available in the email directly by name: {{ customerName }}, {{ order.total }}, and {% for item in lineItems %}…{% endfor %} all work. Values can be any JSON type — text, numbers, true/false, objects, arrays.

The Variables section lists the keys your email needs and offers a starter you can copy straight into the field:

{
  "customerName": {{ customerName | json }},
  "orderName": {{ orderName | json }}
}

Replace every name inside {{ }} with the workflow value it should carry, and keep the | json part — it takes care of quoting and escaping, so text with quotes or line breaks stays valid JSON.

Which keys an email needs

The keys are collected from every block in the email, including the blocks inside a condition, and from every content block it inserts. Conditions decide what is rendered, never what must be passed: an email with four conditional signatures requires the keys of all four on every run. Pass the ones that do not apply as null.

Missing or invalid data

The email is not sent when the data does not match what it needs:

• Invalid JSON in Template data fails the action, and the run log says what was wrong with the JSON.
• A missing key fails the action and the run log names every key that was expected but not passed. A key only has to be present: "note": null and "vip": false are valid values.
• Extra keys the email does not use are ignored.

Images

An image comes either from your Shopify files or from a URL:

• Shopify file: Select an image with the picker on the configuration page. The app asks for permission to read your files the first time you open the image picker. The image is looked up when the email is built, so replacing the file's media in Shopify updates the emails that use it. If the file is deleted, the action fails until you select another image.
• URL: Type an address, or build one with a value such as {{ imageUrl }}. The address must be a public http:// or https:// URL.

Embed the image in the email decides how the image is delivered:

• Off (default): The email links to the image. The message stays small, but recipients whose email app blocks images loaded from the web see nothing until they allow them.
• On: The image is attached to the message and always shows. It is downloaded when the email is sent, so it must be reachable at that moment. An image that cannot be downloaded fails the action rather than leaving a hole in the email. Embedded images are limited to 5 MB each and 10 MB per email.

Only visible blocks are processed at send time: an image inside a condition that is false is neither looked up nor downloaded.

Link targets

A link can point at an http://, https://, mailto:, or tel: address. An address written as www.… is treated as https://.

Content blocks

A content block is a reusable piece of an email, such as a signature or a legal footer. You keep it in one place and insert it into as many actions as you like. Manage them under Settings → Actions → Email.

Preview and test

Two ways to see the email before a workflow sends it, both in the header of the page you are editing on:

• Preview renders the email from the blocks currently on screen and the Test data you entered, and shows it as a recipient would see it. It applies the same checks as a real send: invalid test data, a missing key, or a missing image are reported instead of the email, so what you see is what would actually go out. One thing a preview cannot show: embedded images appear from their web address rather than as attachments, so the 5 MB and 10 MB limits are not checked there. Send test covers that.
• Send test sends the email you are editing to an address you choose. It always goes through your default SMTP server.

Test data lives in the Variables section: a JSON object in the same shape as Template data. It is sample data for the preview and the test send only; a real run always uses the Template data that arrives from the workflow.

Delivery and retries

Every email is sent in both formats at once: the styled HTML and a plain-text version generated from the same blocks for apps that do not display HTML.

A send succeeds as long as the server accepts at least one recipient. Note that acceptance is not the same as delivery: a recipient the server accepts can still bounce afterwards, and that bounce is delivered to the mailbox the message was sent from. It is not reported back to the workflow.

• Temporary failures (for example the server is briefly unavailable, or an embedded image could not be downloaded this minute) are retried automatically.
• Permanent failures (for example missing Template data, a deleted content block or image, or wrong credentials) are not retried — fix the configuration and run the workflow again.

Everything that builds the email happens before the message reaches the SMTP server, so a failure there costs nothing but a retry. Once the server has accepted at least one recipient the action reports success and is never retried.

Output

The action returns the following fields:

• accepted: The list of recipient addresses the server accepted for delivery.
• rejected: The list of recipient addresses the server rejected. Use this in a condition to branch when some recipients could not be reached.