When a new email arrives in a shared mailbox trigger

Having shared mailboxes can help a lot of a team’s productivity. You can have multiple people looking at the same inbox and dealing with emails as they arrive. They are used everywhere, from general teams’ named accounts (accounting, legal, etc.) to mailboxes dedicated to specific tasks (holiday requests, for example). There’s a lot to like about shared mailboxes. Power Automate’s “When a new email arrives in a shared mailbox” trigger allows you to automate processes, making things easier for everyone.

Let’s look at how it works, some of its limitations, and best practices.

Where to find it?

To find this trigger, you can search for “Office 365 Outlook” or navigate through the connectors list, but I always recommend searching for it. It’s faster, and you can usually find it quickly.

Here’s what it looks like when selected:

Usage

The “When a new email arrives in a shared mailbox” trigger has many configuration options where you can get only the emails you need, but let’s start with the most basic configuration options:

Basic configuration

The minimal configuration requires selecting the shared mailbox you want to monitor. This mailbox must be one that you have access to within your organization.

1. Shared Mailbox Address: Select the email address of the shared mailbox from the drop-down list.
2. Folder: Choose which folder to monitor within the shared mailbox. By default, this is set to “Inbox,” but you can select other folders.

Advanced configuration options

Clicking “Show advanced options” reveals additional settings that give you more control over which emails trigger your flow.

Here are some of the options.

1. To: Filter emails based on the recipients in the To field. You can specify one or more email addresses, separated by semicolons.
2. CC: Similar to the To filter, but checks the CC field instead.
3. To or CC: These are similar to the previous ones but a combination of both. So, if an email exists in either “To” or “CC,” it will show up.
4. From: Only trigger the flow for emails from specific senders. Semicolons can separate multiple addresses.
5. Importance: Filter by the importance level (High, Normal, Low).
6. Only with Attachments: When set to “Yes,” the flow will only trigger for emails with attachments. This is useful when you need to process incoming files specifically.
7. Include Attachments: When set to “Yes,” this option will include any email attachments in the trigger output, making them available for processing in later actions. However, large attachments might impact performance, so I recommend not using this option. If needed, you can pick up the attachments with the “Get Attachment (V2)” action.
8. Subject Filter: Only trigger for emails whose subjects contain specific text.

Using trigger outputs

The trigger provides rich information about the email that you can use in subsequent actions. Here are some of the key output properties:

• Id: The global identifier of the message.
• receivedDateTime: When the email was received by Microsoft
• hasAttachments: Boolean value indicates whether the email has attachments or not. This is a good place to validate before looking at the attachments array.
• internetMessageId: Internal UUID of the message. Rarely usable to us.
• Subject: Email subject line
• bodyPreview: The preview of the message in plain text. This is used in places like Outlook to show you some information before you need to open the email.
• importance: The importance level (High, Normal, Low)
• ConversationId: ID of the email conversation.
• isRead: If someone has read the email or not. This is a helpful field in automation, but not in the trigger, since the email will almost always be “unread” when it arrives, or at least when Power Automate picks it up.
• isRead: If someone has already read the email. This is a super useful field in automation because it can allow you to
• Body: The body content of the email (can be in HTML format)
• From: The sender’s email address
• toRecipients: Recipients in the To field.
• ccRecipients: Recipients in the CC field. This field would only be retrieved if the email contains CC recipients. It’s different than the “attachments” because that field will return an empty array if no attachments were found. 
• Attachments: Collection of attachment objects (if Include Attachments was enabled)

Non-intuitive behaviors

There are some behaviors with this trigger that might not be immediately obvious:

The “isRead” only changes when “humans” read it

If you define one or more automatons that get the contents of the email and perform actions, these won’t change the email to “read”. This is expected, otherwise it would make things confusing.

The CC only returns if there’s data

Some people are surprised by this, but if the email doesn’t have anyone in CC, then the JSON field is not even returned. So, if you want to access the information, don’t forget to include the “?” operator to be sure your Flow doesn’t fail, like this.

triggerOutputs()?['body/ccRecipients']

The CC and TO are not arrays

Since both fields could have multiple email addresses, one could think that the field is an array, but it’s not. It’s a string separated by “;”. So if you need an array with the CC or TO fields, you need to use the “split” function like this:

split(triggerOutputs()?['body/ccRecipients'],';')

The ID changes

I’ve discussed this at length in the “How to generate an URL to an email in a shared mailbox?” and “How to generate an URL to an email?” but the important part to know is that if you use the ID to generate an URL you’ll probably have issues. The ID can change slightly when it’s moved from inboxes.

Permissions and access

Even though you’re configuring the trigger with your account, you must have appropriate permissions to access the shared mailbox. If you don’t see a shared mailbox in the dropdown, verify your permissions with your Exchange administrator.

Delay in triggering

The trigger doesn’t necessarily fire immediately when an email arrives. Power Automate checks for new emails at regular polling intervals, which can sometimes lead to delays of a few minutes between email arrival and flow execution.

Body format limitations

The email body is HTML by default. If you need plain text for processing, you must use expressions to convert it or extract text content.

Attachments handling

When you enable “Include Attachments,” each attachment’s content is encoded in base64 format. To work with these attachments in your Flow, you’ll often need to decode them or pass them directly to actions that can handle base64-encoded content. I strongly recommend that you don’t get the attachments initially; only get them if needed. There are other actions that you can use to fetch the attachments; this way, your Flow will trigger and process much faster.

Filter behavior

When using multiple filters (like From, Subject Filter, etc.), all specified conditions must be met for the flow to trigger. The filters work as an “AND” operation, not an “OR.”

Limitations

Be aware of these constraints when using this trigger:

• Maximum email size: The trigger can process emails up to 35 MB (including attachments). Larger emails will be skipped. As mentioned, exclude attachments from the trigger and fetch them only if needed.
• Rate limiting: Microsoft limits how frequently the trigger can check for new emails. High-volume mailboxes may experience delays.
• Shared mailbox access: You can only monitor shared mailboxes to which you have been granted access. Personal mailboxes of other users cannot be monitored unless explicitly shared. This is a given, but I wanted to leave this nevertheless.
• Folder depth: The trigger can only monitor one folder at a time. If you need to monitor multiple folders, you’ll need separate flows for each.
• Deleted items: If an email is deleted before the trigger processes it, the flow won’t execute for that email.
• Rule processing: Server-side rules that move messages might execute before the trigger can detect new emails, potentially causing the flow not to trigger.

This is all I can remember but if you know anything else please write me an email and let me know.

Recommendations

Here are some things to keep in mind.

Use specific filters

Rather than triggering on every email, use the advanced filters to narrow down which emails should start your Flow. Thismakes your flows more efficient and reduces unnecessary executions.

Handle errors gracefully

Email processing can sometimes fail due to content issues or permission problems. Implement error handling in your Flow to catch and manage these situations, rather than letting the Flow fail silently.

Be cautious with the field “isRead”

If multiple people are monitoring the shared mailbox, consider whether automatically marking emails as read is appropriate for your workflow. It might affect how other team members interact with the mailbox.

Consider volume and frequency.

If the shared mailbox receives a high volume of emails, design your Flow to handle batch processing efficiently. For very busy mailboxes, consider using additional filtering or scheduled processing instead of real-time triggers.

Name it correctly

The name is important in this case since we can monitor multiple shared mailboxes and folders. Always build the name so that other people can understand what you are using without opening the action and checking the details.

Always add a comment.

Adding a comment will also help avoid mistakes. Indicate what you’re expecting, why the Flow should be triggered, and what the data will be used for. It’s essential to add comments when limiting the trigger with some custom rulessince these are not prominent in the UI, and people may get confused as to why the Flow doesn’t trigger when it’s simply a rule preventing it from doing so. It’s essential to enable faster debugging when something goes wrong.

An automated trigger is better than a scheduled one.

While you might be tempted to use scheduled triggers that poll the mailbox periodically, the “When a new email arrives” trigger is generally more efficient. It processes emails as they arrive rather than in batches, which provides more real-time automation and makes troubleshooting easier since each Flow run deals with a single email.

… but a schedule can be good too

If the mailbox receives many emails, then not triggering the emails automatically and one by one could have huge gains because you’ll be fetching many emails in one go. So if this is the case, you can consider not using this trigger altogether and using something more efficient that fetches the emails in batches. The only downside is that you need to control the emails you’ve already seen so that you don’t process them twice, so consider this when planning to use this connector.

Final Thoughts

The “When a new email arrives in a shared mailbox” trigger is a powerful tool for teams needing to automate shared communications processes. Whether running a support desk, managing sales inquiries, or coordinating team responses, this trigger gives you the flexibility to build workflows that keep everyone on the same page.

By carefully configuring the trigger options and building thoughtful flows, you can turn a busy shared mailbox from a potential source of chaos into a well-organized system that ensures important messages are handled promptly and consistently.

You can follow me on Mastodon (new account), Twitter (I’m getting out, but there are still a few people who are worth following) or LinkedIn. Or email works fine as well 🙂

Photo by Andrew Dunstan on Unsplash