Email triggers

An email trigger starts a workflow when a message arrives in a mailbox you own. You ask for it the way you ask for anything else. "Run this whenever an invoice lands in my inbox."

This is the one event trigger with no integration code behind it. Reading a mailbox is a protocol the platform already speaks, so the trigger is a short declaration rather than a program, and the platform does the checking itself. Everything else about it works like any other event trigger.

Which mailboxes work

You connect a mailbox with its address and an app password: a password the provider generates for one program, which you can revoke on its own without touching the password you sign in with.

The assistant points you at the provider's own guide when it asks for the password, so you are not hunting for that page yourself.

A mail server that is not on this list works too, as long as it speaks IMAP over TLS. The assistant asks for the incoming server name, the one your mail program calls the IMAP server, and uses the standard port unless you tell it otherwise. That name is not a secret, so it is fine to type into the conversation.

Microsoft mail cannot do this yet

Outlook.com, Hotmail, Live and MSN addresses stopped accepting passwords and app passwords for mail on 16 September 2024. Microsoft 365 work accounts lost the same thing on 1 October 2022. Both need Microsoft's own sign-in instead, and a mailbox trigger built on that sign-in does not exist here yet. If your mail is at Microsoft, this trigger is not available to you today. Say so to the assistant and it will stop offering you an app password for it.

Saving the mailbox signs in to it

When you save the app password, the platform opens one connection to your provider before it stores anything. It connects, signs in, and opens the mailbox read only. Only then does it store the account.

If that sign-in fails, nothing is stored at all, and the card shows you what the server answered, step by step. A refused login is usually a wrong password, a wrong address, or a provider switch that is still off. A failed connect line is usually a wrong server name or port, and you can correct it and try again without leaving the conversation. Your typed values stay in the card.

This is the only moment the platform talks to your mailbox while you are standing there. Everything after it runs on a schedule.

Publishing then resolves the account the trigger points at. A workflow that wants to watch a mailbox with no saved app password behind it refuses to publish and tells you which one is missing.

What the run receives

One message becomes one run. The payload holds:

• the mailbox address the message arrived in, and the folder it was read from;
• the message's own id, and its number within that folder;
• the sender's name and address, the recipients, and anyone copied;
• the subject and the date;
• the body as plain text, cut off at a fixed length, with a flag saying whether it was cut;
• one entry per attachment, holding the file name, the type and the size.

A message that carries no plain text part has its HTML stripped to text before it is delivered. Trigger payloads covers how a run reads any of this.

Timing, and what the first run sees

The mailbox is checked every five minutes, so a message starts its run within five minutes of arriving.

Publishing sets the starting point. Mail already sitting in the mailbox is never replayed, so connecting an inbox with four years of history in it does not produce four years of runs. Only what arrives after you publish starts one.

Each message runs once, however many times the mailbox is read. The platform remembers where it got to, and it opens the mailbox read only from beginning to end. Nothing is marked as read, moved, flagged or deleted, so the mailbox looks untouched to you and to anyone else working in it.

When it stops working

An app password can stop working without anyone doing anything wrong. It gets revoked, the provider's IMAP switch flips back off, or an account password change takes every app-specific password with it.

After three failed checks in a row you get one notification. It names the system and says which of three things happened: the mailbox refused the sign in, the mail server could not be reached, or the mail server answered unexpectedly.

The trigger is not turned off. The platform keeps checking every five minutes, so a mailbox that comes back starts working again on its own with nothing to re-publish. You hear about it a second time only after it recovers and then breaks again, so a mailbox that stays broken over a weekend does not mail you hundreds of times.

What an email trigger will not do

These are current limits, stated plainly:

• No attachment files. You get each attachment's name, type and size. The file itself is not delivered and a workflow cannot open it.
• The inbox, unless you name a folder. Ask for a different folder in the interview and that one is watched instead. One folder per trigger.
• No filtering at the trigger. Every message in the watched folder starts a run. Deciding which ones matter happens inside the workflow, the same as for every other event trigger.
• No sending. This is a trigger, not a mail client. Nothing here replies to a message, forwards one or sends one.
• No cadence of your own. Five minutes, for every mailbox.
• No instant delivery. The mailbox is polled rather than pushed to the platform, so five minutes is the floor rather than a default you can lower.