Having shared mailboxes can help a lot with 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.

This trigger is part of the Office 365 Outlook connector, which is a standard connector, so no premium license is required. The current version (V2) uses the Microsoft Graph API under the hood, replacing the older V1 that relied on the now-deprecated Outlook REST API.

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.

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 that 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.
• isHtml: Boolean value that indicates whether the body content is in HTML format. Useful for deciding how to process the body content in your Flow.
• 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 automations 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 a URL to an email in a shared mailbox?" and "How to generate a URL to an email?" but the important part to know is that if you use the ID to generate a 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. Keep in mind that after permissions are granted, it can take approximately two hours for them to replicate across the platform, so don't panic if it doesn't show up immediately.

Delay in triggering

The trigger doesn't necessarily fire immediately when an email arrives. Power Automate checks for new emails at regular polling intervals, and the frequency depends on your license plan:

• Free plan: Every 15 minutes
• Office 365 plan (E3, E5, etc.) or Dynamics 365 plan: Every 5 minutes
• Power Automate Premium: Faster intervals, configurable

You can check the actual interval by using "Peek code" or "Code View" in the trigger settings, where you'll find the recurrence section with the interval and frequency values.

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."

Moving emails to a monitored folder won't always trigger

The trigger works based on the email's receivedDateTime property. If you move an email from one folder into the monitored folder, the trigger will skip it if its receivedDateTime is before the last successful run. This catches many people off guard because they expect that any "new" email in the folder should trigger the flow, but "new" here means "received after the last check," not "recently moved."

Multiple simultaneous emails may be missed

When several emails arrive at the exact same time, the trigger may only fire for the first one and skip the rest. To handle this, you can enable Concurrency Control in the trigger settings, which allows the Flow to process multiple trigger instances simultaneously. The Split On setting (enabled by default) ensures each email triggers its own Flow run. Disabling it batches all items into a single run with an array input.

Encrypted and digitally signed emails

Encrypted emails are a special case. The trigger output will not contain the actual message body. Instead, it returns a note saying the message is secured and the content is prohibited. If your shared mailbox receives encrypted emails, plan for this scenario in your Flow.

Digitally signed (S/MIME) emails can also cause problems. The trigger output may contain incorrect attachment content that can't be used in subsequent actions. In some cases, S/MIME emails may not trigger the Flow at all.

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: The Office 365 Outlook connector has a throttling limit of 300 API calls per connection per 60 seconds. When exceeded, the service returns an HTTP 429 (Too Many Requests) error. If your Flow does a lot of Outlook-related actions after the trigger, keep this limit in mind.
• 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. For user-to-user shared mailboxes, the user running the Flow needs full access permissions. Having "Send As" or "Send on Behalf" permissions alone is not enough.
• 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.
• One mailbox per trigger: Each trigger instance can only monitor a single shared mailbox. If you need to monitor multiple shared mailboxes, you'll need separate flows for each one.
• 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.
• DLP policies: A Data Loss Prevention policy set by your admin can silently suspend your Flow if the Office 365 Outlook connector conflicts with other connectors in the Flow. If your trigger suddenly stops firing, check with your admin for DLP policy changes.

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. This makes your flows more efficient and reduces unnecessary executions.

Use custom trigger conditions

Beyond the built-in filter parameters, you can add custom trigger conditions using expressions in the trigger's Settings tab. These are evaluated server-side and can prevent the Flow from running entirely, saving your run quota. One important caveat: expression values like "utcNow" are calculated only when the Flow is saved, not on each trigger check, so they become hardcoded values.

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 rules since 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.

Photo by Andrew Dunstan on Unsplash