Mankomail

Email received ​

Starts the workflow when an incoming email matches the conditions.

The Email received trigger starts the workflow when a new email arrives in one of your mailboxes and matches its conditions. It is the only trigger that brings a triggering email: every node that acts on that email (reply in the thread, Move, Flag, the AI nodes reading the body) can be used after it. The email is read with {{ email.… }}, not under data; data starts empty and fills up with the outputs of the steps.

The conditions are a tree of rows combined with "all" or "any", the same as in the Condition node. With no condition, every eligible email of your mailboxes starts the workflow. The fields and operators are described in Triggers and conditions.

A workflow can hold several Email received triggers, one per set of conditions. Use Manual run instead when the workflow should only start when you ask for it.

At a glance ​

  • Type: trigger.email · version 1
  • Category: Triggers
  • Kind: Trigger — starts a run
  • Effect: No external effect (none) — nothing is written outside Mankomail; safe to replay
  • Needs a carrier email: No
  • Connection: None
  • Outputs: main

Parameters ​

conditions ​

Conditions — Which emails start this workflow. No condition = every email in your mailboxes. Attachments are fields like any other: "has a PDF attachment" reads attachments.mimeTypes contains application/pdf, and "has an attachment" reads attachments.count greater than 0 (signature logos do not count).

  • Type: Condition tree (conditions)
  • Required: No
  • Tests the fields of the incoming email

multiMatch ​

When several workflows match

  • Type: One choice (options)
  • Required: No
  • Default: inherit
  • Options:
    • inherit — Follow my setting: The policy from your preferences decides when several workflows claim the same email.
    • all — All of them fire: Every matching workflow gets its own execution.
    • priority — Only the first one: Exclusive routing, mail-rules style: the highest-ranked workflow wins.

Outputs ​

  • main — Taken by every run this trigger starts: the email matched the conditions.

Data produced ​

What this node adds to the run data, and how to read it in an expression. <step> stands for the step key: the node name turned into an identifier (see Data and expressions).

  • {{ email.subject }} — string. Decoded subject of the triggering email. Empty string when the email has none.
  • {{ email.from.email }} — string. Sender address, normalised (domain in lowercase).
  • {{ email.from.name }} — string. Sender display name, when the email carries one.
  • {{ email.to }} — array of { name, email }. Recipients. email.cc, email.bcc and email.replyTo have the same shape; email.to.0.email reads the first address.
  • {{ email.receivedAt }} — string. Reception time recorded by the provider, ISO 8601 in UTC. email.sentAt holds the date declared by the sender, when present.
  • {{ email.bodyText }} — string. Decoded plain-text body, derived from the HTML when the email only has HTML. email.bodyHtml holds the HTML body, not sanitised.
  • {{ email.attachments }} — array of { filename, mime, size, disposition }. Attachment metadata (no content). disposition is attachment or inline; size is in bytes. email.attachments.0.filename reads the first name.
  • {{ email.folderLabels }} — array. IMAP folders or Gmail labels carried by the email.
  • {{ email.flags.seen }} — boolean. Read flag. email.flags also has flagged, draft and sent.
  • {{ email.signals.isAutoReply }} — boolean. Signal computed at ingestion. email.signals also has isNoReply, isMailingList and isFromSelf.
  • {{ email.threadProviderId }} — string. Thread identifier at the provider (Gmail thread, Graph conversation), when known.

Example ​

Process supplier invoices sent as PDF. Add an Email received trigger with conditions set to "all" of:

from.domain             has domain   supplier.example
attachments.mimeTypes   contains     application/pdf

Publish the workflow. When an invoice arrives, a run starts on the main port. Downstream, a node can write:

Invoice from {{ email.from.name }} — {{ email.subject }}
First attachment: {{ email.attachments.0.filename }}

Tips ​

  • Only new emails trigger: emails received after the mailbox was connected, delivered by synchronisation (not by the initial import of the history), and inside your scope. Emails in Sent, Spam, Trash and Drafts never trigger.
  • Built-in guardrails discard, before any workflow sees them, emails sent from your own mailboxes, automatic replies, mailing-list messages and messages from no-reply addresses. Such an email never starts a run, whatever the conditions.
  • One email starts at most one run per published version of a workflow. If two Email received triggers of the same workflow match the same email, only one run is created, and the run detail shows which trigger claimed the email.
  • When several workflows match the same email, the policy applied is the one set in your preferences ("My trigger policy" on the scope page): every matching workflow runs, or only the first one in priority order. The "When several workflows match" parameter of this node does not override that preference today.
  • The trigger is armed on publication. A paused workflow keeps its arming but starts no run until it is resumed.
  • To test, pick an email from your mailboxes in the editor: the test runs the draft on that email in a test run (see Test runs).
  • A path that does not exist (an email without Cc, for example) renders an empty string and records a warning on the step; the run does not fail.