Incoming Email (v2)
The Incoming Email trigger in Automations v2 starts a run when an email arrives at the address Files.com generates for the Automation. It is the trigger for partners and systems that send files by email. A supplier emails invoices as PDF attachments, a nightly report is emailed as a ZIP archive, or a scanner emails each document it processes.
Files.com generates the address when you save the Automation and shows it with the Automation.
Sender Restrictions and Email Authentication
Allowed Senders matches each message's From address against the addresses or domains you configure. Use an address such as invoices@example.com for one sender, or *@example.com for every sender in that domain. Messages with a From address outside the list are rejected. Leaving Allowed Senders empty accepts email from any sender, subject to the site's inbound email checks.
The site's Inbound email authentication setting applies to Inboxes and every Incoming Email Automation on the site, including Workspace-owned Automations. When enabled, it authenticates the From domain using SPF, DKIM, and DMARC results before checking Allowed Senders. A message that fails authentication is rejected even when its From address is allowed or the sender list is empty.
When the setting is off, the From address is not authenticated. Allowed Senders then limits only the address a message claims to come from: anyone who knows the Automation's email address can put an allowed address in From. To restrict processing to approved senders, have a Site Administrator enable inbound email authentication and configure Allowed Senders for the Automation.
A rejected message fails the trigger, so later nodes do not process its attachments, body, or complete-email capture. Check the trigger's error in run detail to distinguish an authentication failure from a sender that is not allowed. For authentication failures, ask the sender to review its domain's email authentication configuration and any forwarding service involved.
What the Run Starts With
Each attachment becomes one file item. You can also capture the body or complete message as additional file items, depending on what the next steps need to read:
| Capture | File item | Use |
|---|---|---|
| Save Body | email-body.txt for the plain-text body, or email-body.html when an HTML-only email supplies the body. | Process the message body. Plain text is preferred when the email supplies both versions. |
| HTML body | email-body.html, only when the email has a nonempty HTML body. | Preserve the supplied HTML, including table structure and formatting. Plain text is not converted to HTML. |
| Complete email | email.eml, containing the received headers, body, and attachments. | Send a complete message to an email tool or existing .eml processing workflow. A message with no attachments or body can still produce this item. |
HTML body and complete-email capture are off by default and can be enabled independently of Save Body. Attachments remain separate items even when they are also included in email.eml.
For an HTML-only message, enabling both Save Body and HTML capture produces two distinct body items, both named email-body.html. Enable only one if the next step needs one copy of that body.
Every item carries the sender's email address as attributes.sender, the subject as attributes.subject, and the message's date and time as attributes.received_at. The timestamp is an ISO 8601 value from the email's Date header.
These values are available to TransformScript expressions in later nodes. For example, {{ attributes.received_at }} in a Set Metadata value records the message's timestamp on the file.
These file items start as temporary files inside the run, rather than files in a folder. A Copy File or Move File node saves each one to the folders you choose and passes the stored destination files to later nodes. A Delete File node connected after Copy File or Move File deletes those stored files; it cannot delete a temporary file received directly from the trigger.
The run retains its temporary content for other branches and reruns under the run's retention rules. Moving or deleting a stored copy does not remove that retained content, and no Delete File step is needed to clean up the temporary files.
Incoming File Pattern and Exclude Pattern select every type of file item by name, including body captures and email.eml. File Limit caps the number of items remaining after those filters.
Items are considered in this order: Save Body, HTML body, complete email, then attachments. For example, when the body and complete email both pass the patterns, a File Limit of 1 keeps the body item and leaves out the complete email and attachments. Choose the captures, patterns, and limit together for the files the next step needs.
Incoming Email vs. Inboxes
An Inbox also receives attachments and can save body or complete-email captures directly in its folder. Use an Inbox when the goal is to collect files in a folder. Use an Incoming Email trigger when those files need processing as they are received, with the nodes after the trigger determining where each one is written.