Workflow actions

Send email

This Workflow Companion action sends a plain-text email through an SMTP server that you configure. Use it to notify staff, email customers, or alert an external mailbox as part of a workflow.

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.
  • Body (required): The plain-text content of the email. The body is sent as plain text, so HTML markup is not rendered by the recipient's email client.
  • 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.

SMTP server

The email is sent through one of the SMTP servers configured in the app settings (Settings → Actions → SMTP servers). The action configuration 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.

With Set in the workflow, the SMTP server name field is required and its value must match the name of a server in your app settings — matching ignores capitalization and surrounding spaces. If the name matches no server, the action fails and the run log lists the names that do exist. With any other option, the field must be left empty.

Renaming a server in the app settings breaks workflows that select it by the old name.

SMTP servers (app settings)

Manage servers under Settings → Actions → SMTP servers. Each server has:

  • Name: A label to recognize the server in the action configuration, and the value workflows use to select it by name.
  • Host and Port: The address of your SMTP server. The host must be a public address.
  • Connection security: STARTTLS (typically port 587) or Implicit TLS / SSL (typically port 465).
  • Username and Password: Credentials for authenticating with the server (required).
  • From email and From name: The sender identity used on outgoing messages.
  • Default: Exactly one server is the default. The first server you add becomes the default automatically.

Server names must be unique within your store, ignoring capitalization.

Two checks on the server form work on the values currently in the form, so you can use them before saving:

  • Test connection verifies the host, port, connection security, and credentials.
  • Send test email sends a short message to the address in Send test email to. This is the stronger check: it also proves the server accepts your From email and relays to that recipient. A successful result means the server accepted the message — check the inbox and the spam folder to confirm it arrived.

Security

Usernames and passwords are stored encrypted. The password is never shown again after saving — leave it blank when editing to keep the stored value.

Delivery and retries

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 server's From email mailbox — it is not reported back to the workflow.

  • Temporary failures (for example the server is briefly unavailable, rate-limited, or greylisting) are retried automatically.
  • Permanent failures (for example wrong credentials, or every recipient rejected as unknown) are not retried — fix the configuration and run the workflow again.

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 (including any that were not valid email addresses). Use this in a condition to branch when some recipients could not be reached.