Skip to main content

Microsoft 365 E-Mail

The Microsoft 365 E-Mail integration lets a pipeline consume messages from an Office 365 (Exchange Online) mailbox through the Microsoft Graph API, using an Azure app registration and the OAuth2 client-credentials (app-only) flow. A configured mail folder acts as a work queue: every message in it starts the pipeline, and once its run succeeds the message is moved to a Done folder.

Typical use: an accounting inbox where suppliers send invoices as PDF attachments — the pipeline stages each attachment for OCR/AI analysis, then files the mail away.

NodeKindPurpose
FromMicrosoftGraphEmail@1TriggerPolls a mailbox folder via Microsoft Graph, downloads file attachments, runs the pipeline once per message, and moves the message to a success folder on completion.
Which e-mail trigger should I use?
  • FromMicrosoftGraphEmail@1 (this article) — Microsoft 365 / Exchange Online via Graph and an Azure app registration. No password stored; folder-as-queue semantics with automatic move-on-success.
  • FromEmail@1 — any IMAP server (host / username / password). Use this for non-Microsoft mailboxes or where app registration is not an option. See the FromEmail@1 node reference.
  • SendEMail@1 — outbound SMTP send. See the SendEMail@1 node reference.

Architecture

  1. The trigger acquires an app-only token from the Entra token endpoint (https://login.microsoftonline.com/{tenantId}/oauth2/v2.0/token, scope https://graph.microsoft.com/.default).
  2. It polls the configured folder (path resolved from the mailbox root — not the inbox, unless the path points there) and fetches the oldest messages first.
  3. For each message it starts the pipeline with a batch of exactly one message, so success maps 1:1 to the per-message action. Only fileAttachment contents are downloaded (base64); item/reference attachments are skipped.
  4. On a successful run the message is moved to moveToFolderPathOnSuccess (the leaf folder is created if missing). On failure the message stays put and is retried on later polling cycles, up to maxAttemptsPerMessage times per adapter lifetime.

Unified message shape

FromMicrosoftGraphEmail@1 emits the same structure as FromEmail@1, FromMicrosoftGraph@1 and FromTeamsBot@1, so a downstream pipeline can be channel-agnostic. Each message is an element of $.Emails[]:

$.Emails[0].Subject — message subject
$.Emails[0].From — sender (display name + address)
$.Emails[0].FromAddress — sender address only (e.g. user@example.com)
$.Emails[0].To — recipients
$.Emails[0].Date — received timestamp
$.Emails[0].Body — message body
$.Emails[0].MessageId — Graph message id
$.Emails[0].Attachments[0].FileName
$.Emails[0].Attachments[0].ContentType — MIME type (e.g. application/pdf)
$.Emails[0].Attachments[0].Length — content length in bytes
$.Emails[0].Attachments[0].Data — base64 file content

Because the trigger delivers one message per run, pipelines typically wrap the body in a ForEach@1 over $.Emails (a single element) and an inner ForEach@1 over $.key.Attachments.

Credentials

The trigger reads its credentials from a MicrosoftGraphConfiguration entity — the same configuration type used by the Teams triggers — resolved by WellKnownName through a System.Communication/Uses association on the pipeline. Its three attributes map directly onto the Azure app registration:

AttributeAzure value
AzureTenantIdDirectory (tenant) ID
ClientIdApplication (client) ID
ClientSecretClient secret value

Continue with the step-by-step Setup.