Skip to main content
Send email is the action that sends one of your emails when a flow reaches it. Meridian’s emails go out only through automations, never as manual one-off campaigns, so every send is tied to something that happened. The other actions a flow can take are Send Slack message, Populate custom field, and Wait.

​
Choosing the email

Pick one of your emails in the step’s configuration. The step keeps a snapshot of that email’s subject, preview text and HTML, and the snapshot is what sends: the action doesn’t re-render or re-fetch the email at run time. Saving the email updates the snapshot on every step that uses it, at once, in every automation of the app, active or not. That holds wherever the save comes from: the email builder, the email’s own page, Meridian’s API, or email_update in Meridian MCP. The next run sends the new version, and a flow you open afterwards already shows it, with nothing to save. A run already paused on a Wait keeps the version it started with. Because each save reaches live flows straight away, rework an email that a live automation sends on a copy: Duplicate it from the email’s More actions menu, edit the duplicate, then activate it and pick it in the step when it’s ready.

​
Who it goes to

Three recipient modes: Store merchant (the default) is the email on record for the store that triggered the run. For an app hosted on Meridian, Meridian reads it from Shopify when the store installs, unless your app sends its own email to identify, which Meridian keeps over Shopify’s. For an app hosted elsewhere, Meridian can’t reach Shopify for it, so it’s the email your app passes to identify or mintShopToken. In that case the step reads the address when it runs, so one that arrives after the run started still counts, as long as it arrives before this step. Store contacts are the named people Meridian knows at that store:
  • Principal contacts: the Shopify-verified account owner, plus contacts you added by hand. A manually added contact counts as principal: adding one says “this is the person I talk to”.
  • Everyone we know: one email per named person at the store.
  • Include collaborators is off by default. Collaborators are agencies and freelancers working in the merchant’s admin; they’re usually not your customer, and lifecycle email aimed at the merchant reads badly to them.
A store fans out to at most 20 recipients in one send. Beyond that Meridian truncates and says so, rather than quietly emailing a prefix of the list. If no named contact matches, the send falls back to the store’s own email (the Store merchant address, read the same way), so no store is skipped for want of a contact. Specific people is your own list: organization members picked from a panel, or typed addresses. This mode ignores the triggering store’s email and uninstall state entirely, so it’s the one to use for internal notifications.

​
Uninstalled stores

A store that has uninstalled is not emailed in store or contacts mode, because its token is dead and the mail is unwanted. Uninstalled is the deliberate exception, because off-boarding email is the point of that trigger. Sends addressed to specific people are unaffected.

​
Variables

The subject and body substitute variables at send time: store variables, the triggering event’s own variables, your custom fields as custom_field_<handle>, and, in contacts mode, the recipient’s name. A token that no longer exists renders as an empty string rather than leaking {{braces}} to a merchant.

​
Where it sends from

The sending domain configured for the app: your verified domain, or Meridian’s platform sender until you add one.

​
Gating the send

Put a condition in front of it (segment membership, or a variable from the trigger or the store) so the email only reaches part of your base. Every send is recorded, and its open, click and conversion rates roll up into email analytics.
Last modified on September 30, 2026