Skip to main content

​
Email Trigger

An email trigger issues a pair of addresses for a flow. Mail sent to either one starts the flow, with the message’s contents as $.trigger. You do not receive mail at your own domain — you forward to the issued address from a mailbox you already have.

​
Getting your addresses

1

Add an Email trigger

From the Add Node panel. Open the node and choose the Trigger tab.
2

Press Get

The button reads Get the first time and Get New afterwards.
3

Copy both addresses

They appear as To trigger draft flow and To trigger published flow.
The trigger node is the only place these addresses are shown. There is no list of them elsewhere in the product.

​
The format

<name> is generated for you — two adjectives, a noun and a number, such as sparklyjollybubble650. Both addresses are plus-address variants of the same real mailbox, and they differ only in the literal draft prefix. This makes the email trigger the easiest one to test against: send to the draft address while you are building, switch to the published address when you go live.
Addresses are re-issuable, not permanent. Pressing Get New generates a fresh pair and replaces the ones on the node. The previous pair is not revoked — it is simply forgotten by the trigger, so anything still forwarding to it stops working with no error anywhere. Update your forwarding rules before you press it.

​
Forwarding mail to it

Set your existing mailbox to forward to the issued address. The trigger node’s Email Forwarding tab links to each provider’s own instructions:

Gmail

Settings → Forwarding and POP/IMAP

Outlook / Hotmail

Settings → Mail → Forwarding

Yahoo Mail

Settings → Mailboxes → Forwarding

Apple iCloud Mail

Mail settings → Forwarding
Most providers make you confirm the destination before forwarding starts, by mailing it a code. The issued address cannot show you that message, so forward selectively with a filter where your provider supports one, or use a provider that confirms by a link you can approve from the sending side.
A provider-side filter is the only way to narrow what reaches the flow. Everything that arrives starts a run, so forward the mail you actually want processed rather than the whole mailbox.

​
What the flow receives

$.trigger is a flat object with eight keys and nothing else:
email_from is an array, not a string. Used in a concatenation it renders as ["sam@example.com"], brackets and quotes included. Write $.trigger.email_from[0] wherever you want the address itself.
There is no to, no cc, no reply-to, no message ID and no header map in the payload. A flow cannot see who else the mail was addressed to. There is also no node-id level: $.trigger.email_trigger.email_from and anything like it resolves to nothing — the eight keys sit directly under $.trigger.

​
Attachments

Attachments are stored as objects and referenced by key, not delivered inline.
  • $.trigger.attachments_bucket names the bucket.
  • $.trigger.email_attachments lists the object keys, in the form email_<uid>.<filename>.
An Assistant step in the flow receives the files automatically — they are attached to the run as knowledge, so it can read them without a fetch step. Other steps read the object store by bucket and key.
An attachment that fails to store is skipped: the run still starts, and that file is simply absent from email_attachments. Attachments are retained for the account’s configured log-retention window rather than indefinitely.
There is no size limit enforced by the trigger. The practical ceilings come from your provider’s own inbound limit and the platform’s message-size limit, and a message over them fails before the trigger sees it.

​
Draft and published flows

This is the one trigger where the draft/published split is handled for you: the two addresses are the switch.
What runs after the trigger is decided by each step’s outcome, not by the arrows in the editor. A Condition step’s outcome names the step IDs to run next — one, several (they start at the same time), or the reserved RESOLVE_SUCCESS / RESOLVE_ERROR to end the run. A line drawn between two steps that no outcome names is decoration.

​
Seeing what arrived

Monitoring → Emails lists every message that reached a flow: status, sender, flow, attachments and timestamp. Opening one shows the body and its attachments, and offers Re-trigger to run the flow again on the same message, and Delete. That surface is genuinely useful, but be clear about what it does and does not tell you.
success means the flow was started, not that it worked. A run that then errors still shows success here. Flow failures live in the flow’s own run history, not on the email record.
Mail that fails to match a flow leaves no record at all. If the address has been re-issued, the flow deleted, or the address mistyped, nothing appears in Monitoring, no bounce is sent and the sender is told nothing. The message is silently dropped.
A message is delivered once, with no retry. If processing fails after the message is picked up, it is not tried again and does not reappear. Use Re-trigger where a record exists; where none does, the message is unrecoverable.
Delivery normally takes seconds. There is no guaranteed latency and nothing reports how long it took.

​
Security

Anyone who learns a trigger address can run your flow with any content they like. There is no sender allowlist, no SPF, DKIM or DMARC check, no spam filtering and no rate limit. The address itself is the only secret.
Treat an issued address as a credential:
  • Do not publish it, and do not use it as a public contact address.
  • Validate $.trigger.email_from[0] in the flow’s first step and stop the run when the sender is not one you expect.
  • Press Get New if an address leaks — but update your forwarding first, and remember the old one is orphaned rather than revoked.

​
Troubleshooting

Check the address character for character, including the + part. Then check whether Get New has been pressed since the forwarding rule was written — that replaces the addresses.
The address did not resolve to a flow. That produces no record. It is nearly always a typo or a re-issued address.
The issued address cannot show you incoming mail before a flow exists to process it. Build a minimal flow that logs $.trigger.email_body, publish it, then start the forwarding setup and read the code out of the run.
Read both $.trigger.email_body and $.trigger.email_html_body — a mail sent as HTML only populates the second.
email_from is an array. Compare $.trigger.email_from[0].
It failed to store. The run went ahead without it; there is no retry for that file.
That status only covers starting the flow. Open the run itself to see where it failed.

​
Next Steps

Assistant Step

Reading an attached document

Condition Step

Checking the sender before doing any work

Variable Mapping

Reading the message in later steps

Triggers Overview

Every way a flow can start